Archive
Another handy little tool, Move On Boot.
Upon receiving a new dll from a support provider recently, I could not replace the existing file, as the file was in use by the system. A restart to safemode also wielded the same result. Dang!
I wanted to use the PendingFileRenameOperations registry key to instruct windows to copy a file during the boot process.
The issue with this key and behavior is that in order to tell windows to delete a file, the next line to the source file must be blank… if you manually try to add a blank line to regedit you receive the following error!
I needed an application to move a file during the boot process of windows before the service or handle held the file I wanted to replace open. I decided to write a new tool called MoveOnBoot.exe.
MoveOnBoot leverages the PendingFileRenameOperations registry key and the MoveFileEx Api to move the file on boot simply and easily.
Move on boot does the following:
- Adds the copy jobs to the PendingFileRename key you specify.
- Copies the new file into the target directory with an _newer file extension.
- Optional: instructs windows to copy the current file to a _old extension
- instructs windows to replace the target file with the _Newer file.
How to use it:
Simply select the source and destination files as below:
Optionally choose to backup the target file during the operation with the check box above.
Once you have added all the files you need to replace, you can check the queue by going to file > view pending operations:
And that’s it! restart the device and let windows do the hard work.
Optionally, if you chose to backup the file as part of the operation, you will find an _old file in the target directory as below:
Download:
Support information:
- Requires Administrator privileges.
- Requires .net framework 2.0 or greater.
Using powershell as a replacement for the Change Logon command in Remote Desktop Services.
Still on my PowerShell buzz for the week, this is post 2 of 3 on some Remote Desktop Services / XenApp Powershell goodness!
This is one I’ve been meaning to post for quite some time, but other things got in the way. Mainly me forgetting how to use most of the powershell native methods due to having my head stuck in .net the last few weeks… Moving on…
While trying to find a method to check the status of logon’s to a Remote Desktop server via PowerShell, I didn’t have much luck. Either people are string scraping the output of the command using select-string or going to the registry and checking the raw Value with get-itemproperty. I wasn’t happy with either approach so I dug down into WMI and found the following.
From what I’ve found, the settings for enable, disable and the two drain modes are stored under the namespace root\cimv2\terminalservices. Under the class Win32_terminalservicesetting.
There are two properties we are interested in here:
- logons (0 = enabled, 1 = disabled*)
- SessionBrokerDrainMode (0 = Disabled, 1 = DrainUntilRestart, 2 = Drain)
*why oh why 1 is disabled is beyond me, but I digress.
The order of priority is enabled / disabled first, before the drain options are referenced.
So what does this tell us? Well, a change logon /query is simply performing the following simple checks:
Change Logon /query
gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices" | %{
if ($_.logons -eq 1){
"Disabled"}
Else {
switch ($_.sessionbrokerdrainmode)
{
0 {"Enabled"}
1 {"DrainUntilRestart"}
2 {"Drain"}
default {"something's not right here!"}
}
}
}
Ok that’s great and all, we’ve now replicated change logon /enable, but how do we set these values?
Easy! Using the native PowerShell $_.put() method, we can push values back in.
Below you will find each “Change Logon” option in server 2008 R2 and the corresponding WMI property.
Change logon /Enable
$temp = (gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices") $temp.sessionbrokerdrainmode=0 $temp.logons=0 $temp.put()
Change Logon /Disable
$temp = (gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices") $temp.logons=1 $temp.put()
Change Logon /Drain
$temp = (gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices") $temp.sessionbrokerdrainmode=2 $temp.put()
Change Logon /DrainUntilRestart
$temp = (gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices") $temp.sessionbrokerdrainmode=1 $temp.put()
And that’s it! now if you want to wrap this up in a function be my guest, or if you would like me to do so just drop me a line.
Caffeine for Citrix Receiver!
In this post I’m announcing a new little tool from my lab for managing power saving and screen saver settings while using the Citrix Receiver for windows. I’ve been using this tool for months, I love it and miss it when I use a workstation without this tool. I’ve also sent this out for feedback to a select few experts in the VDI market space and the feedback was very positive.
That being said, this tool will be welcomed by some (users) and hated by others (admins). I’m a bit torn about whether to publish it or not so if you want to add to the feedback drop me an email on andrew@andrewmorgan.ie.
A big thanks to Mike Stanley, Kees Baggerman, Simon Pettit & Dan Garcia for the feedback!
Caffeine will also be available in the next release of ThinKiosk.
The Mission statement:
Often when using the XenApp, XenDesktop or even Citrix VDI in a Box, double prompting for passwords from windows devices is both common and a pain in the backside. When you’re local workstation locks out you need to re input your workstation password, then re input your password again in the remote session… irritating and unnecessary.
From a security perspective its necessary to configure a secure screensaver on their desktop in the datacenter to ensure any connecting device receives a password prompt when the user is idle a certain amount of time, but it can be a management nightmare to exclude users from receiving double password prompts from managed windows devices.
Removing the double password scenario:
This issue extends from desktops, to laptops and to thin clients too and it often bugged me how often I spent entering my password twice each day.
With Caffeine for receiver, you install a lightweight application that runs in the system tray. This application automatically attaches to Receiver sessions (via the ICA Client Object) and sends a keep alive every minute to ensure the remote screen saver never kicks in. Leaving just the local secure screensaver to lock the users out.
This works really well from Enterprise devices with double screensavers or home devices that are secure by default. This also allows you to keep your secure screensaver policies on the datacenter side and work around them from managed devices.
Sleep settings:
As a father, I struggle to find alot of time to work while my son is awake. Often I’ll start working on something and get dragged away for hours only to return to my pc asleep and my remote session disconnected and logged off due to policies. This infuriates me and I disable sleep on most of my devices for this reason… Which is costing me a fortune in electricity!
Further to just screensaving, Caffeine can also be configured to stop computers from going to sleep while a remote session is active. This will keep your pc awake when you are running a remote session if you need to step away but allow it to sleep when you don’t have a remote session… Best of both worlds!
If you still wish to use power saving while on battery, this is still available as above.
Wasted resource?
Well if I’m sending a keep alive from my enterprise device this means the sessions will never reach enough of an idle timeout to satisfy idle timeout policies. Which from an admin perspective mean’s these sessions will never terminate unless the remote machine is restarted.
With Caffeine you can configure these idle time-outs for managed devices via the settings (above) or via GPO meaning you can mirror your idle time-out settings…and dare I say feel confident they’re work reliably for once!
But.. but.. but.. security!!! We can’t have users turning off their secure screensavers!
Well, yes. This is the conflict of interest here, users want it and the admins wont! In order to make Caffeine as secure as possible I’ve included the following options for enterprises:
Caffeine requires administrative permissions to install:
By default only administrators of their local machines will be able to install Caffeine.
Enterprise Kill Pill:
Caffeine has a “Kill Pill” built in, you can download the enterprise GPO to stop Caffeine from working on your devices.
Secure screensaver requirement:
By default caffeine will only work if a secure screensaver is present locally. If the user attempts to remove the screensaver after login, they will be alerted and Caffeine will no longer keep the sessions alive:
Advanced Access Control.
Using Advanced access control with access gateway you can target machines running caffeine and exclude them from using your citrix environment.
Availability:
The Caffeine for Citrix Receiver beta is now available for download.
Pre-Requisits:
- .Net Framework 2.0
- Citrix Receiver 3.2 and upwards.
Tested Platforms:
- Windows 7 x64
Download:
Adding Windows Media Player Codec’s to Windows Thin PC.
By default when you install windows thin pc, you get access to windows media player without codec’s. If you are using Windows Thin PC for Citrix products these codecs are vital for correct HDX Mediastream redirection.Below you will find a few quick and dirty steps to include the necessary codec’s in your Windows Thin PC image:
Acquiring the Codec’s:
1: Head over to the microsoft download site and download the Windows Embedded Standard 7 Service Pack 1 Tookit (part’s 1 to 8)
2: Once fully downloaded, run the Standard 7 SP1 Toolkit.part01.exe and extract the contents to a folder (e.g. c:\toolkit)
3: Once fully extracted, browse to C:\toolkit\Standard 7 SP1 Toolkit\DS\Packages\FeaturePack (where the extract folder was c:\toolkit).
4: In this folder, you will find the codec’s stored in folders beginning with “x86~winemb-premiumcodecs
5: Make a new folder in your c: drive called codecs, and copy the contents of the above folders into this new folder. The folder should appear as below:
6: Once we have the codec’s we can now integrate them using two methods, we can add them to a current machine, or add them to an installer image. Both Method’s are included below:
Online Method:
1: From a Windows Thin PC, run the following command from an administrative command prompt:
Dism.exe /Online /Add-Package /PackagePath:C:\codecs /NoRestart
Integrating the Codec’s into an image:
1: Extract your ISO copy of the Windows Thin PC to c:\windows_thin_pc
2: create a new folder to mount the image to, called c:\mnt
3: Run the following command from an administrative command prompt:
Dism.exe /Mount-Wim /WimFile:C:\Windows_Thin_PC\sources\install.wim /index:1 /MountDir:c:\Mnt Dism /Image:c:\Mnt /Add-Package /PackagePath:c:\codecs Dism.exe /Unmount-Wim /MountDir:c:\Mnt /commit
4: Once this completes, add your image back to Microsoft WDS, or write it to a usb key or DVD.
Note: if the command prompt reports DISM.exe is unavailable, grab a copy of the Microsoft WAIK.
Thinkiosk: Turn your current PC’s into Citrix ready thin clients, with minimum hassle.
Note:
this post is a reference to the 1.0 release, please go to http://www.andrewmorgan.ie/thinkiosk for the latest information or use the menu’s above.
With alot of uncertainty in the Citrix Thin Client market (Citrix SoC), the increasing demands for client offloading (HDX redirection) and the abundance of suitable hardware in your current infrastructure, there has never been a greater need for hardware recycling.
Using current defunct hardware to provide a better experience to the user can slash the cost of new customer roll outs and also provide a stop gap solution as we all patiently wait to see what Citrix will deliver with their System on Chip design.
With this in mind I recently set about evaluating products in this market. I tested both Linux based distro’s and the Citrix Desktop appliance lock.
- The linux devices had driver related issues and didnt support the full feature list of Citrix’s HDX technologies.
- The Citrix Desktop Appliance lock (although great) lacked control and flexibility.
Ultimately, not satisfied with my options I decided to develop my own solution to this Problem
ThinKiosk:
The product I have developed, ThinKiosk, is a lightweight .Net framework application designed to replace the shell of the pc it runs on. ThinKiosk is free to use and the source code will also be available for further development.
ThinKiosk is a secure browser window that is designed to leverage the configuration and flexibility provided by the Citrix Web interface. Thin Kiosk allows the users to use multiple desktops, applications etc and adds additional configuration options to empower the user. Allowing users to configure screen resolution, keyboard, audio etc without allowing too much access to the pc.
With ThinKiosk you can present multiple desktops or individual applications to whoever logs into the kiosk.
ThinKiosk allows companies to leverage all of the Citrix HDX components, along with the Branch repeater plugin on top of hardware capable of client side rendering, at no additional cost.
As ThinKiosk will run on Windows devices, you can use your current antivirus and Windows Update products to manage these devices. No extra configuration, no messing.
Licensing:
ThinKiosk is free to use for any individual or business. So feel free to use it!
That being said, I don’t consent to ThinKiosk being used as follows:
- Included as part of a bundle package.
- Integrated into a “paid for” service
- Sold as a service.
Deployment:
ThinKiosk can be deployed using an MSI and a very simple Group Policy ADM file.
ThinKiosk has been designed to replace the windows shell option using the Group Policy Custom User Interface option. This allows you, as the administrator to replace the shell based on computer or user policies, Allowing quick fall back to the native desktop during testing.
Tested Configurations:
The below operating systems have been tested with HDX and Flash redirection:
- Windows XP.
- Windows Thin PC.
- Windows Media Player 11
- Internet Explorer 8 & above
- Adobe Flash Player 11
- Citrix Receiver Enterprise 3.1
- Microsoft .net framework 2 to 3.5 sp1.
.net framework 4.0 has mixed results
Setup:
ThinKiosk can bedeployed to an auto login account, domain or local. Thin Kiosk can also be configured to run as the end user. The setup options are flexible to how you wish to deploy it.
A recommended configuration for ThinKiosk would be to configure an auto login account on the PC’s, so when the PC boots it auto logs in presenting the web interface for the user to log in as themselves.
This allows for quick boot times, removes any complications provided by the users group policies and allows users to fall back to their own profile in the event of missing functionality during initial testing.
Group Policy Configuration options:
Below are the configuration options available in the ADM file:
URL – The Web Interface URL.
E.G. http://citrix/Citrix/XenApp
ShowAdminMenu – Displays an admin menu in thinkiosk.
This admin menu contains cmd, explorer, a custom url and resizing options. These tools are handy for troubleshooting
ShowLogOff – Displays the LogOff button to the users.
Allowing a user to log off.
WindowMode – Displays ThinKiosk in a window instead of fullscreen.
Window mode allows users to stack open applications at the bottom of the screen, handy for users who need multiple applications.
WindowModePercent – The percentage of the primary monitor to be used by ThinKiosk.
e.g. 90%
Auto Login Options:
As part of the Group Policy template, I’ve configured options to make configuring the default login as part of the policy. These options aren’t currently available in Microsoft Group Policies and have been provided for extra value. These settings Dont need to be used.
Registry control:
All configuration of ThinKiosk is via the ADM file, but the corresponding registry keys will be published for non domain use below:
ThinKiosk checks both machine and user keys on load in that preference.
Machine keys take preference over user keys.
- HKEY_LOCAL_MACHINE\SOFTWARE\ThinKiosk
- HKEY_CURRENT_USER\SOFTWARE\ThinKiosk
Recommended Group Policy:
Citrix Web Interface Considerations:
Below are some quick fire recommendations to make the web interface configuration faster and easier.
Dedicated web interface site for ThinKiosk:
As a number of the configuration options needed for ThinKiosk will not suit a standard web interface site, I suggest you configure a dedicated site for ThinKiosk.
Session time out:
As users will be authenticating on this web interface then most likely launching a desktop, I suggest a session time out as low as 5 minutes.
Default ICA file options:
Below are a few Default ICA options that are useful for ThinKiosk:
Forcing the use of the desktop viewer:
[ApplicationName] .... connectionbar=1 TWIMode=Off
Force the Citrix receiver to use full screen:
[Application] ... DesktopViewer-ForceFullScreenStartup=true
Download:
head over to the downloads page for more information.
Known issues:
- The first login after installing the receiver causes ThinKiosk to hang on client detection.
Update: this issue only happens with < Web interface 5.3, Web interface 5.4 works fine. If this does happen, just restart the endpoint.
Future Improvements:
- Multi User language packs for Spanish, Greek and French are being developed.
- Central management for Shutdown and Boot options.
- Keystroke to enter admin mode. This is in progress and expected soon.
- Auto add the Web interface to Trusted Sites.
Feedback:
I’m really interested in feedback and your use case for ThinKiosk, drop me an email on andrew [at] andrewmorgan [dot] ie and let me know what you like and more importantly, what you need.
Credits:
A big thank you to@shanekleinert for initial testing and feedback.
Translations:
A big thank you to the following people for providing translation help:
- Dutch Language and ADMX files - @dennis_van_dam
Profile:
Donate:
If ThinKiosk or any of my blogs, scripts or applications were useful to you, please consider donating!
Recent Comments