First post - be gentle...
I have given some support staff access to the read-only view of Veeam ONE Monitor client for our vSphere environment.
I achieved this by adding them to the Users group on the Veeam ONE server.
Everything works as expected and is proving to be very useful however there is one piece which does not see to function as expected.
We are using the product in Infrastructure View to check on machines in error (e.g.Windows 7 running high VM CPU usage).
If a machine is experiencing an issue in this area then the support staff member uses the Process option to use guest OS authentication to view the processes, this works as expected.
The problem arises when the user wishes to kill an errant process (say AcroRd.EXE at 100% or something like that)
On highlighting the required process then clicking the Kill Process button an Access Denied message is displayed.
If I add the user to the Administrators group on the Veeam ONE Server then try exactly the same process (including the exact same Guest OS credentials) then the process *can* be terminated.
Is this a bug?
-
- Novice
- Posts: 6
- Liked: 2 times
- Joined: Apr 20, 2013 9:57 am
- Contact:
-
- Novice
- Posts: 6
- Liked: 2 times
- Joined: Apr 20, 2013 9:57 am
- Contact:
Re: Veeam ONE Monitor
Quick update.
I have established that the Kill Process button uses the users AD logged on context - not the guest OS credentials as supplied when viewing the process.
This can be worked around by ensuring the users logged on AD account has local administration rights to the managed VM's - not ideal but it works.
I have established that the Kill Process button uses the users AD logged on context - not the guest OS credentials as supplied when viewing the process.
This can be worked around by ensuring the users logged on AD account has local administration rights to the managed VM's - not ideal but it works.
-
- Product Manager
- Posts: 20400
- Liked: 2298 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Veeam ONE Monitor
The dev team confirmed that this is by design. So, it seems that you’ve found the only potential workaround – adding a domain user to a local admin group on a target VM.Is this a bug?
Anyway, thanks for the feedback; highly-appreciated.
Who is online
Users browsing this forum: No registered users and 168 guests