When using xendesktop, users typically have two options inside a session, logoff and disconnect. If they choose disconnect, the session is closed on their client, however, the session continues to run on the server until they log back on or some other event causes it to logoff (ie: an idle time setting). For some the disconnect option is not desired and perhaps even causes more trouble then it helps. You can remove this option from the sessions with a simple group policy as described below.
Open GPO editor and create a new policy. Link the policy to the appropriate location based on where you want it to apply.
Edit the policy and change the following to "enabled"
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Remove Disconnect option from Shut Down dialog
Older server versions may have this option listed under Terminal Services. If you do not see the options above you may try looking here instead.
Reboot the client computers and there you have it, no more disconnect button.
Showing posts with label Citrix XenDesktop. Show all posts
Showing posts with label Citrix XenDesktop. Show all posts
Thursday, January 13, 2011
Thursday, November 18, 2010
Citrix XenDesktop – Printing with Meditech
By Jeff Dixon
November 18, 2010
When we first set out on our journey to setup XenDesktop not enough thought had been given to one of our primary applications, Meditech. Meditech is the most used and widely deployed application we have and prior to XenDesktop, Meditech had been running in XenApp for remote users for some time. Due to this I believe it was thought that it would work equally as well in XenDesktop and with the exception of one oversight that was correct. Printing was this oversight.
Let me explain a little further, how much of our printing works for Meditech. We have what we call the Capture printer. The capture printer is a software driven printer that goes back to a mapping of computer to printer names. There is a database that maps computer names to printers. There is also an application that takes the print job and expands upon it. When a certain request is sent to the Capture printer it will typically print several items of varying quantity and to various locations. For example, it may print two copies of a report to tray one, a set of labels to tray two, and a wrist band to another printer from this single print submission.
Have you seen the problem that has arisen? With XenDesktops the hostname may be different every time. Additionally, many of our users work in different areas at different times. So User A may sometimes be working in department 1 and sometimes in department 2. No matter where she is logging in she needs to be sure she is printing to the correct printer(s) for that location.
There were three main issues I had to overcome in order to get this to work.
1. When Meditech printed, it had to see the hostname of the current session. While Meditech worked great from XenApp, the application was running from the server and therefore thought it was printing from the server. This was obviously an issue and it had a simple fix. I installed Meditech onto the Image.
a. Residual Issue – We run another program, Emdeon Assistant. This program launches and integrates with Meditech. This program also ran fine inside XenApp however with Meditech running on the image and Assistant running in XenApp they no longer played nice together. End Result, I had to install Assistant onto the image as well.
2. At this point I was able to get Meditech to print through the capture printer correctly but the problem was the hostname would change every time a user logged in and the hostname needed to be mapped to a particular printer. Now I know this is not the only way to resolve this but in order to continue using pooled desktops this was the only resolution I found to this issue.
In order to overcome the problem, each group of desktops that printed to the same printer was setup in one desktop group. So every computer that printed to printer A was in desktop group A and all computers printing to printer B would log into desktop group B.
3. This brings me to the last issue, Citrix Appliance Lock. Users log into different computers that print to different printers which means different desktop groups. Citrix Appliance Lock will only log a user into the first desktop group they have access too by alphabetical order. There is no way to change this and no option to select another group by the user. Since I’m primarily using repurposed desktops for my clients, I want the underlying OS to be hidden from the user and I want the user to have a seamless logon to the XenDesktop session. The Appliance Lock did what I desired but had a serious limitation in choosing desktop groups. I was able to resolve this by changing the Windows logon shell to a batch file and launching the session from there. I’ve written in much detail about this in the previous post, so please refer to it for more detail on this.
I’ve been running several very heavy users with this setup, most of which who are not overly tech savvy and the feedback so far has been very positive. There are a few definite changes to get use to in using XenDesktop but it also has a number of advantages. While we have yet to widely deploy this to everyone due to time and numerous applications that must be addressed, it is looking promising.
Citrix XenDesktop - Resolution to Desktop Groups and the Appliance Lock
By Jeff Dixon
November 15, 2010
Forward:
I’m admittedly new to XenDesktop and many of the related Citrix applications. Over the past few months, however, I've been working on configuring, testing, and deploying a XenDesktop environment. In doing so I've run into many road blocks and I’d like to share how I’ve overcome one of these such road blocks. While the end solution was not overly complicated, I’ve tried to be fairly detailed and list things I’ve tried and learned that I felt worth sharing during this particular challenge.
If you would like to skip the details and just get to the point, I have a quick summary at the end that lists how to apply this process.
Scenario:
Problem:
Using Citrix Desktop Appliance Lock, the first desktop group (alphabetically listed) will always launch upon login. This cannot be changed.
Not using the Appliance Lock meant users would have to log into the desktop and either launch the desktop icon for the appropriate group if the online receiver is installed or they would have to log into the portal and launch it that way. Granted there are some work a rounds and variations to this but generally there was no transparent way for the user to log in and immediately be entered into their appropriate virtual desktop. I tried several things to try and automate it as much as possible and this is what evolved into my solution below.
November 15, 2010
Forward:
I’m admittedly new to XenDesktop and many of the related Citrix applications. Over the past few months, however, I've been working on configuring, testing, and deploying a XenDesktop environment. In doing so I've run into many road blocks and I’d like to share how I’ve overcome one of these such road blocks. While the end solution was not overly complicated, I’ve tried to be fairly detailed and list things I’ve tried and learned that I felt worth sharing during this particular challenge.
If you would like to skip the details and just get to the point, I have a quick summary at the end that lists how to apply this process.
Scenario:
· Old Windows box, need to repurpose as XenDesktop client.
· Users need to log into a particular desktop group depending on computer location. Each computer, however, will always log into the same desktop group.
Problem:
Using Citrix Desktop Appliance Lock, the first desktop group (alphabetically listed) will always launch upon login. This cannot be changed.
Not using the Appliance Lock meant users would have to log into the desktop and either launch the desktop icon for the appropriate group if the online receiver is installed or they would have to log into the portal and launch it that way. Granted there are some work a rounds and variations to this but generally there was no transparent way for the user to log in and immediately be entered into their appropriate virtual desktop. I tried several things to try and automate it as much as possible and this is what evolved into my solution below.
Solution:
Part 1 - the batch file
The first major evolution I had in creating a fix was a batch file. Now before I go much further let me state for the record. I am not a programmer. I know without a doubt that another programming language could make this simple script look much better and if one of you programmers out there would like to convert my process into a program that would look much better than my dos screen I welcome it. I just ask that you would share the code back with me as a courtesy.
Now I’ve wrote a couple variations of this bat file to do a few different things just testing ideas and possible improvements. In the script below, as the session logs off, the bat file simply logs off the computer. Additionally I have a variation (not shown here) that would prompt the user to transfer/open their session if they are the same person as the user who is logged on the computer or if they would like to log off the computer. The idea here was if a XD session was transferred from computer A to computer B, when the user walked back to computer A they could hit Y and pull their session right back instead of logging off and back in again in order to transfer the session. If a different user walked up they would hit N to say no that is not my username log off. Then they could log on as them. This essentially just involves adding an IF THEN statement to the script and is pretty easy to do. Of course there are plenty of variations that using this method allows for so you can get as creative as you’d like here.
The bat file does the following:
Prevents itself from being closed
If an admin (or specified user) logs in, it launches explorer and closes
If a user logs in it launches the XenDesktop (desktop group specified in path)
Finally it logs off the computer to prepare for the next login
If an admin (or specified user) logs in, it launches explorer and closes
If a user logs in it launches the XenDesktop (desktop group specified in path)
Finally it logs off the computer to prepare for the next login
Here is the Batch file and I’ll explain some more below:
@echo off
TITLE Loading Desktop....
TITLE Loading Desktop....
mode con:cols=25 lines=5
noclose
IF "%username%" == "administrator" GOTO EXPLORER
cls
"C:\Program Files\Citrix\ICA Client\pnagent.exe" /CitrixShortcut: (2) /QLaunch "XDFarm:GroupNameHere"
sleep 5
TITLE Click and press any key to Logoff
mode con:cols=120 lines=55
echo.
echo Logging off...
echo.
echo.
echo Click this window, then press any key to logoff
pause > nul
shutdown -l -f
exit
:EXPLORER
explorer.exe
exit
noclose – you can take this out if you desire but here is what it is and why it’s there. If the bat file were closed the user would be left looking at a blank screen and I didn’t want this. Noclose is a small application that simply disables the X button on the cmd window. This was a bit hard for me to find online so I’m sharing it here again. As stated before, I’m not a programmer and Google is my friend. This program was found here (http://www.computing.net/answers/windows-xp/how-to-prevent-a-cmd-window-from-being-closed/180624.html) and the code is below:
#define _WIN32_WINNT 0x0500
#include <windows.h>
int main()
{
DeleteMenu(GetSystemMenu(GetConsoleWindow(), FALSE), SC_CLOSE , MF_GRAYED);
DrawMenuBar(GetConsoleWindow());
return 0;
}
The site also lists a compiled version here (http://www.megaupload.com/?d=XCH3FBWS). Please refer to the link above if you have questions or issues with this particular code.
Sleep – this stalls the commands in the file long enough for the XD to launch before moving on. This way, all the user sees is the small black screen saying launching desktop. Granted, if it takes to long for it to launch they will see the screen change, increase in size and prompt for logoff so this time can be tweaked as needed. Also note that the sleep command is not present in all versions of windows and may need to be added. Both sleep and noclose commands were copied to the system32 directory on computers where this process was deployed.
"C:\Program Files\Citrix\ICA Client\pnagent.exe" /CitrixShortcut: (2) /QLaunch "XDFarm:GroupNameHere"
**Important Note** this bat file is using the Citrix online receiver and this must be installed for this to work.
The link above is the path to launch the XenDesktop and specifies the desktop group. When you log into the desktop with the receiver installed as a user that has access to a group, icons for the groups to which the user has access will appear. You can copy the shortcut path of the link to get the appropriate path for your environment. It should be something very similar to the path above.
Step back
Before the next step which is a small but critical one, my bat file above had a few variations. I originally was running this file from the startup folder in the all users profile. I did this initially on one client and then four more as a test phase. It worked fine but it still did one thing I didn’t like. When the user logged in they saw their desktop on the physical computer. The batch file killed the explorer process so that when logging off they didn’t see their desktop (as they know it) anymore. The thing was, they still saw the desktop on the underlying OS for a few seconds every time they logged in prior to XenDesktop launching. As many of us are often impatient, this meant the second they saw that first desktop, they wanted to start clicking away. Surely there was a way to improve upon this and there was. After removing the command to close explorer and a few other small changes (resulting in the file above) I came up with this simple but great solution.
Part 2 – Changing the Windows shell
Explorer.exe is the default Windows shell. My first thought was so simple it seemed too good to be true and while it worked it didn’t work as I would have liked and let me explain.
My first thought in this phase was to simply set the link to the desktop group as the new Windows shell. Now let me say that this is simple to do and it does in fact work. But there are some things to be aware of and for me I didn’t like the way it worked so I chose a different method. If you do this and apply it to the machine there is no way to log back into a different shell to change it. It could likely be done remotely over the network but what a inconvenience that would be. Second, when you log out of the XD session you are left with just a blank screen. I don’t know about your users, but many of mine would be lost for what to do next. Ctrl+alt+del and log off will get you out of this but that can be asking a lot from some users. My theory is to always make things as simple and fool proof as possible for the user.
What I did instead was to use my batch file. I set the shell to the batch file and so far this has worked great! The XenDesktop launches very quickly from login because it doesn’t have to bother loading all the normal junk with explorer. Users are transparently logged into the XD session and it looks like they are logging into a normal desktop for the most part, much like if the appliance lock were installed. In fact, when this setup is deployed, there is very little difference in the experience from this (aside from the underlying ability to choose a desktop group) and the appliance lock with one exception, logoff. When you log off a XD session you are now prompted with a large dos window. Clicking in the window and pressing any key logs you off. There is no other option and nothing else that can be clicked, closed, or opened. The exception would be if additional commands were added to the file for further actions at this time.
The windows shell can be changed for all users with this key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="c:\\vdi.bat"
Part 3 – Putting it all together
I created a folder with four files
1. A registry file that changes the Windows shell to the default explorer.exe
2. A registry file that changes the Windows shell to the bat file
3. A bat file that simply logs off the machine (for convenience only when logged on as admin)
4. A bat file that controls Citrix and all the rest as shown above
The third file is completely optional. I put it there because I’m lazy and it’s faster to click the bat file to log off than to ctrl+alt+del and log off.
The two registry files; with the bat file, when you log in as administrator it simply opens an explorer window. From here you can run the default registry file to change the shell back, perform administrative tasks and when you’re done run the other registry file to re-enable the bat file as the shell.
**Batch file Idea** What if you need the user to be able to choose from different desktop groups instead of setting it for them? Well you could let them do it the traditional way by clicking on a desktop link if the online receiver is installed or by logging into the portal, but maybe you don’t want them to see the desktop or to have to log in more than once. You could still use the method here by simply entering user prompts at the beginning of the batch file to ask which group to launch. For example you could say, press 1 for group A, press 2 for group B and so on then go from there. This method is very versatile and can be used to overcome many scenarios.
Summary
Install Citrix Online receiver
Create bat file from commands provided (or create your own version)
Create registry file with default shell and one with the modified path to the bat file
Place files onto drive and apply registry change
Reboot and login to your XenDesktop session
Batch File: (noclose and sleep may need to be added to system32 dir, path to desktop group should reflect the path for your environment)
@echo off
TITLE Loading Desktop....
mode con:cols=25 lines=5
noclose
IF "%username%" == "administrator" GOTO EXPLORER
cls
"C:\Program Files\Citrix\ICA Client\pnagent.exe" /CitrixShortcut: (2) /QLaunch "XDFarm:GroupNameHere"
sleep 5
TITLE Click and press any key to Logoff
mode con:cols=120 lines=55
echo.
echo Logging off...
echo.
echo.
echo Click this window, then press any key to logoff
pause > nul
shutdown -l -f
exit
:EXPLORER
explorer.exe
exit
Windows Shell: (Modified to run bat file)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="c:\\vdi.bat"
Subscribe to:
Posts (Atom)