With the release of VMware Horizon Workspace many of us are evaluating it and testing this in our labs. When you install the vApp it creates 5 VMs each of which are allocated a certain amount of vCPU and memory which while sized for production can be overkill for some PoC and definitely lab environments.
To help with evaluating this is a resource constrained environment it is possible to reduce the resource allocation to each of the VMs after deploying the VM.
If you are only evaluating this is your lab you may be able to squeeze these settings down further to save resources. The one I would not touch is the Data-va as reducing it further is known to cause issues.
Test the changes to make sure it doesn't cause any timings issues and remember this is not supported.
Monday, 8 April 2013
Wednesday, 23 January 2013
Running Multiple Instances of the View Client
Have you ever wanted to launch multiple View instances as different users but from the same client?
I'll start by saying that this is unsupported and should not be used in production.
This can however be very useful in set up and testing where you may want to remain logged into one desktop as an admin user and log in and out of another as a standard user.
What is supported is the use of command line parameters that you can pass to the View Client. If you open a CMD prompt and run "C:\Program Files\VMware\VMware View\Client\bin\wswc.exe" -? you get a list of the possible parameters.
This allows you to create short cuts with the following:
"C:\Program Files\VMware\VMware View\Client\bin\wswc.exe" -serverURL https://<connectionserver> -userName Test1 -domainName DEMO -password testpassword -desktopName "Pool Name"
Very useful as it stops us having to specify the test user, password, etc. each time, but we can only run a single instance of the View Client.
To run multiple instances of the View Client we can add an undocumented switch -Standalone. This allows us to have multiple instances of the View Client logged in as different users each in their own Window.
To do the equivalent on a MAC:
Just remember the use of the -Standalone switch and running multiple instances is unsupported.
I'll start by saying that this is unsupported and should not be used in production.
This can however be very useful in set up and testing where you may want to remain logged into one desktop as an admin user and log in and out of another as a standard user.
What is supported is the use of command line parameters that you can pass to the View Client. If you open a CMD prompt and run "C:\Program Files\VMware\VMware View\Client\bin\wswc.exe" -? you get a list of the possible parameters.
This allows you to create short cuts with the following:
"C:\Program Files\VMware\VMware View\Client\bin\wswc.exe" -serverURL https://<connectionserver> -userName Test1 -domainName DEMO -password testpassword -desktopName "Pool Name"
Very useful as it stops us having to specify the test user, password, etc. each time, but we can only run a single instance of the View Client.
To run multiple instances of the View Client we can add an undocumented switch -Standalone. This allows us to have multiple instances of the View Client logged in as different users each in their own Window.
To do the equivalent on a MAC:
- In Finder browse to Applications
- Right click the VMware View Client and select Show Package Contents.
- Browse into Contents and MacOS.
- Double clicking on vmware-view will open a Terminal Window and launch a new instance of the View Client.
Just remember the use of the -Standalone switch and running multiple instances is unsupported.
Monday, 14 January 2013
Disconnect Idle Users in View
[Updated] Windows 7 64-bit corrections. While originally tested on Windows 32-bit there are some changes required for 64-bit Windows.
I was recently asked if there was a way to disconnect idle users from a View session. The motivation and use case was to free up shared or public thin clients so they weren't locked up and then inaccessible to other users.
I had a look around and found an excellent screensaver from GrimAdmin.com. This allows you to define an action to carry out when the screensaver kicks in and after a wait time has expired. It comes with predefined actions such as Logoff but also allows you to define an external process which allows us to call a process to disconnect the user. What was missing was an ADM template to make this easy to apply to a GPO but the author had documented the registry settings so I put one together.
There are three steps to configure this:
Extract the scr file from the GrimAdmin file and install it into your desktops into the C:\Windows\Systems32 directory. In a View environment the easiest way is to copy it to the parent VM and recompose to get it on all the linked clones.
[Update] For Windows 64-bit copy the scr file to the C:\Windows\SysWOW64\ directory.
Step 2
Now we can configure our GPO to enable a screensaver, set the idle time to wait before starting the screensaver and which screensaver to run.
Under the User Configuration section browse into Polices, Administrative Templates, Control Panel, Personalization. Change your settings to match the values below.
The value for the Force specific screen saver should match the 8.3 name of the Screensaver from GrimAdmin. This should be Screen~1.scr but you can check by doing a DIR /X
[Update] For Windows 64-bit specify the whole path to the screensaver. C:\Windows\SysWOW64\SCREEN~1.SCR
Configure the Process that we want to run. To disconnect a user we can run the process c:\Windows\System32\tsdiscon.exe
Note that this will only disconnect the user session but will leave them logged into the View desktop.
[Update] For Windows 64-bit use c:\Windows\Sysnative\tsdiscon.exe Because the screensaver is a 32-bit process, the OS would try and redirect any call to a 64-bit process in System32 to the SysWOW64 directory by default. Using the alias Sysnative tells Windows to use System32 anyway.
Define how long we want to wait from the screensaver starting to when it executes the external process and disconnects the user.
Define a custom message to get displayed to the user warning them that they are about to get disconnected.
I use the following but use the variables and whatever will make sense to your users.
"No user activity has been detected for quite a while. You will be disconnected unless you cancel within %time_remaining% seconds."
The other settings I used was to increase the font size of the message to make it a bit more noticeable. Test this though to make sure your message fits in the window with your font size.
That's it. When the group policy is applied when the user logs they should now get the screensaver set and they should be unable to change it.
After being idle for the defined period in the Screen saver timeout they will get the following message.
This will then countdown the number of seconds defined in the Delay In Seconds. If they do nothing they will get disconnected. If they click Cancel they reset the idle clock.
I was recently asked if there was a way to disconnect idle users from a View session. The motivation and use case was to free up shared or public thin clients so they weren't locked up and then inaccessible to other users.
I had a look around and found an excellent screensaver from GrimAdmin.com. This allows you to define an action to carry out when the screensaver kicks in and after a wait time has expired. It comes with predefined actions such as Logoff but also allows you to define an external process which allows us to call a process to disconnect the user. What was missing was an ADM template to make this easy to apply to a GPO but the author had documented the registry settings so I put one together.
There are three steps to configure this:
- Download and install the GrimAdmin screensaver
- Configure GPO personalization to enable the screensaver.
- Configure GPO to specify GrimAdmin actions.
Step 1
To get started, download the bits we'll need:Extract the scr file from the GrimAdmin file and install it into your desktops into the C:\Windows\Systems32 directory. In a View environment the easiest way is to copy it to the parent VM and recompose to get it on all the linked clones.
[Update] For Windows 64-bit copy the scr file to the C:\Windows\SysWOW64\ directory.
Step 2
Now we can configure our GPO to enable a screensaver, set the idle time to wait before starting the screensaver and which screensaver to run.
Under the User Configuration section browse into Polices, Administrative Templates, Control Panel, Personalization. Change your settings to match the values below.
The value for the Force specific screen saver should match the 8.3 name of the Screensaver from GrimAdmin. This should be Screen~1.scr but you can check by doing a DIR /X
[Update] For Windows 64-bit specify the whole path to the screensaver. C:\Windows\SysWOW64\SCREEN~1.SCR
Remember to set the number of seconds that you want to wait until the screensaver starts in the Screen Saver timeout. For testing I've got this quite low at 60 seconds in most environments this is going to be higher depending on how long you want to wait before considering a user idle.
Step 3
Now we need to configure the GrimAdmin Screensaver to carry out the operation we want. To start we need to add in the adm template you should have downloaded into our GPO. Right click the Administrative Templates under User Configuration and select Add. Browse to where you saved the adm template and select it.
You will now get and new section under the Classic Administrative Templates called Screensaver Operations in which we can set the various registry keys that control GrimAdmin's Screensaver.
Configure the Process that we want to run. To disconnect a user we can run the process c:\Windows\System32\tsdiscon.exe
Note that this will only disconnect the user session but will leave them logged into the View desktop.
[Update] For Windows 64-bit use c:\Windows\Sysnative\tsdiscon.exe Because the screensaver is a 32-bit process, the OS would try and redirect any call to a 64-bit process in System32 to the SysWOW64 directory by default. Using the alias Sysnative tells Windows to use System32 anyway.
Define how long we want to wait from the screensaver starting to when it executes the external process and disconnects the user.
Define a custom message to get displayed to the user warning them that they are about to get disconnected.
I use the following but use the variables and whatever will make sense to your users.
"No user activity has been detected for quite a while. You will be disconnected unless you cancel within %time_remaining% seconds."
The other settings I used was to increase the font size of the message to make it a bit more noticeable. Test this though to make sure your message fits in the window with your font size.
That's it. When the group policy is applied when the user logs they should now get the screensaver set and they should be unable to change it.
After being idle for the defined period in the Screen saver timeout they will get the following message.
This will then countdown the number of seconds defined in the Delay In Seconds. If they do nothing they will get disconnected. If they click Cancel they reset the idle clock.
Subscribe to:
Posts (Atom)