Remote Desktop printer\Log off issues

OS: windows 2003 Server 2003 SP1
Program: Remote Desktop \ Printers

Users that are utilizing RDP Client (the latest) to log on to the server are experiencing extended profile loading\unloading.
I installed UPHClean.exe and it logs the issue to the Event Viewer. These are some of the errors:

EventID 1501 Source: Userenv

The following handles opened in user profile hive servername\username (S-1-5-21-601176114-2260491871-370163669-1032) are preventing the profile from unloading:

winlogon.exe (5752)
HKCU\Printers\DevModePerUser (0x364)

EventID 1517 Source: Userenv

Windows saved user Iservername\username registry while an application or service was still using the registry during log off. The memory used by the user's registry has not been freed. The registry will be unloaded when it is no longer in use.

This is often caused by services running as a user account, try configuring the services to run in either the LocalService or NetworkService account.

EventID 1401 Source: UPHClean

The following handles in user profile hive IPDMEZ0301MIA\dsunno (S-1-5-21-601176114-2260491871-370163669-1032) have been remapped because they were preventing the profile from unloading successfully:

winlogon.exe (3476)
HKCU\Printers\DevModePerUser (0x364)

When this happens a few things result:

1. The user will call me telling me how they had trouble logging on or off the server
2. They couldn't see their printer or had trouble printing so they tried logging off to get back on but it was delayed as above
3. The spooler jumps up to 50% of the CPU
4. If they DO make it back onto the server, the printers from the previous session is still in the printers\faxes folder
5. this happens if people time out on the server and then log back in as well.

Does anyone have any suggestions on what I can do to make sure that the profiles are unloading and taking the printer with it? Even if they time out? I know that's what UPHClean.exe is supposed to do, and it's helping - but the issue is still there.

Thank you for all your help!! =)

ZadeyTech,

Is there some reason you're still running Server 2003 SP1 instead of SP2? I ask because I believe there are specific issues addressed by SP2 that MIGHT solve this problem.

Check out:

http://support.microsoft.com/kb/914962/en-us

I realize that in some cases, SP2 is NOT desireable due to incompatibility with mision critical 3rd party applications installed/running on Server 2003. If this is the case, let me know and I can attempt to help you solve the problem under SP1. If you don't have any reason for NOT upgrading to SP2, I would do that FIRST, then see if this problem still exists.

Hope this helps.

- John Hook

ZadeyTech, I just thought of a few follow questions that might better help me to help you solve this problems. 1) You're using are connecting to a WIndows 2003 Server via terminal services running on this server - correct? 2) What client OS are your users running? XP? 3) Are the printers they are attempting to access via Remote Desktop printers locally connected to their client PC? 4) When your users end their remote desktop session with the server, are they logging off or simply "disconnecting"? 5) What type of networking protocols are the users connecting with - i.e. straight TCP/IP via a LAN or some VPN tunneling protocol via the Internet? I would still recommend trying the SP2 instalation if your environment permits it, but knowing the answers to these questions would be helpful. - John Hook

ZadeyTech,

Is there some reason you're still running Server 2003 SP1 instead of SP2? I ask because I believe there are specific issues addressed by SP2 that MIGHT solve this problem.

Check out:

http://support.microsoft.com/kb/914962/en-us

I realize that in some cases, SP2 is NOT desireable due to incompatibility with mision critical 3rd party applications installed/running on Server 2003. If this is the case, let me know and I can attempt to help you solve the problem under SP1. If you don't have any reason for NOT upgrading to SP2, I would do that FIRST, then see if this problem still exists.

Hope this helps.

- John Hook

Hi John,

You know - that is something that I completely didn't look into. The server is hosted by a company in Miami and I will call them and find out why! thank you!!

–Penny

Edit: I just called them and they said that they haven't approved SP2 because it conflicts with my NIC driver . (i've never heard of it, but I asked them to do what they have to do and bring it up).

ZadeyTech, Thanks for the feedback - this helps. I've found that accessing remote printers, whether in a home networking environment, a Remote Desktop / Terminal Services environment or in a Windows Domain environment - sharing permissions and username/password authentication can often be the culprit if you experience printer connections that once worked, then stop working. Usually, I've found that the problem is a caused by the user having different usernames/passwords on the device that's sharing the printer and the remote system that their trying to access it from. Are your client's PC's and user accounts set up on your Server 2003 Domain? If so, are they logging into their client PC's with the same username/password that has been configured on their Domain account(s)? I've found that if there's any difference between the two - there are passthrough authentication problems when it comes to acessing shared folders, printers and other resources via remote desktop or even straight LAN connections. Your problem seems to be about more than just printers - but also with user profiles when connecting/disconnect to/from your server. There are several settings in 2003 Server's profile and remote access settings that can affect the behavior of remote access and user profiles. There are also some global Terminal Services settings that might be at play in your environment. All of this is stuff to consider - but I would FIRST check with the hosting company about WHY they're not running Server 2003 SP2. It would be pointless to troubleshoot and implement possible solutions to problems that might simply be known BUGS in Server 2003 SP1. Make sense? Anyways, Hope this helps. - John Hook

Thanks for looking in on this thread John. Much appreciated.

Hi John, It makes perfect sense! The excuse the hosting company gave me about not approving SP2 because it would conflict with the NIC card and its drivers didn't make sense - so i went ahead and changed the NIC to an auto-detect, downloaded SP2 and other updates to date and I have to wait until the middle of next week to really see if there are any issues. I don't have Active Directory set up on this server, so all accounts are local and the client machine user names and pass's differ. Users log on to the server, work on 2 programs for accounting and print, then log off. I've set up the server to time people out after 15 minutes and then log them off if they remain disconnected for an additional 15. I really wish i could enforce that they log off if they're walking away from their desk , but it's a bit hard in the sales environment. I just keep an eye on it and either log them off myself or shoot them an email\call. Although much will be taken care of with all your help (which reinforced what i was thinking, i just need to get there), i know that the problem will mostly lie with the users. As this company grows, I will probably have to create a completely different environment and activate AD…. I cleared and saved the event log and will keep you updated in the coming week. Thank you so much for your help! You've given me alot to consider and I will probably implement some if not all… Have a great weekend! –Penny

ZadeyTech, Again, your feedback helps paint a clearer picture of your environment - allowing me to offer more contructive advice. 1) Hopefully you've been able to sucessfully download & install Server 2003 SP2. I'm not saying that SP2 is going to "cure" all of your issues, but it will at least rule out any bugs that were fixed between SP1 and SP2. 2) Regardless of whether or not you have "Active Directory" services running - what troubles me is that the user's client username/passwords DIFFER from the usernames/passwords configured for those users on your Windows 2003 Server. When the user launches the "Remote Desktop" connection, is that RD connection configured to connect to the Domain? Generally, to allow the server to connect to a remote desktop client PC's printer, that local printer needs to be SHARED and the connection on the Remote Desktop site needs to be able to connect to the client's printer via username/password authentication. For example, when I connect a remote desktop session to one of the Domain PC's on my office LAN (from HOME), if I want to set up one of my HOME printers to print from that Remote Desktop client PCs - I need INSTALL the home printer (provided it is SHARED) on my Remote Deskop Client PCs. When I initially go to connect to this printer from the remote client - it needs a USERNAME & PASSWORD on my local desktop that will allow it access the the shared printer on my local PC. ALL of this said - making the local username / password the SAME as the user's username/password on the Server will allow Windows to do "passthrough" authentication - i.e. automatically grant access because the server & local usernames/passwords are the SAME. 3) YES it DOES sound as if the users aren't properly logging off from their Terminal Services connection on your Windows 2003 Server. Provided you have Admin access on your server, you should be able to go into the "Terminal Services Configuration Administrative Tool" and set your "disconnect" and "reset timeout" settings so that when a user's session breaks, all processes in that user's session will be terminated.: Go into Control Panel, Administrative Tools, Terminal Services Configuration, Select "Connections" on the left, the right-click on "RDP-TCP" on the right. click on "Properties", the click on the "Sessions" tab. THIS is where you can force a disconnection by checking the "Override User Settings" box and changing the setting(s) in the drop-down list. Hope this helps. - John

Hi! So, update: 1)SP2 installed successfully and the issue that is prevalent is that profiles aren't logging off\on fast enough. 2) The Remote Desktop Client has the settings to log onto the server and automatically connects the printer from the local machine. The server can print to it given that the driver installed on the server is the same version as the client logging on to it. It'll be remapped to a PRN port for the user while they are logged on. 3) This was the first thing I did to try to curb the people that keep logging off properly, but it's still happening. That's when i started using the UPHclean.exe utility and noticed the event errors below. I have to do a bit more research and see if anyone else is experiencing this really strange issue. I found an updated Beta version of the UPHClean.exe utility, but i want to try it out on a tester box before throwing it into a live environment and making my problems worse. I will keep you posted! Once again, thank you so much for your feedback. It's definitely helping me realize what else i can do and that i'm also thinking in the right direction.

ZadeyTech (Penny),

While it's unfortunate that SP2 didn't provide a quick fix to your problem, it sounds like you got a much better grasp of the issue and are closer to a workable solution.

Your user's TS (Terminal Services) sessions are clearly NOT being closed in a clean an orderly manner. In a perfect world, all users would have the sense to exit any/all running applications, make sure there are no active print jobs in their queue and perform a "Logoff". Instead, for a variety of reasons - sessions are being "disconnected", which by default leaves the users TS session running on the server. There IS value in the ability to "disconnect" in some settings. If configured properly, the user can reconnect to their “disconnected” session on the server, leaving them where they left off. In an environment with MANY users, this is probably not wise considering the load and resources placed on the server with too many sessions running all at once. That said - the best practice would be to have users exit all applications and "logoff" of their session. Doing so should cleanly remote the running session from the Server, releasing memory and processor bandwidth for the next user(s).

The TS Configuration Time-out settings might be an issue as well. Ending a disconnected session forcefully removes the running session from the server. If that session has running applications (your accounting program) or active mappings to drives/printers - these connections/programs are forcefully terminated - which is problematic as connections to database servers, application settings and other connected resources are not properly closed. Each session is basically a virtual copy of windows running on the server. Forcibly terminating the session is comparable to yanking the power cord from a Windows PC where a user is logged in and running applications. Not a good idea! Timeout settings could have the undesired effect of corrupting user application data, connections and settings because they can either “disconnect” active sessions then eventually forcefully TERMINATE these sessions.

In a NON-DOMAIN environment, you're limited in the restrictions and timeout options you can configure. I don't believe the NON-DOMAIN Terminal Services controls allow you to force a session "logoff"In a DOMAIN (Active Directory) environment, you can impose very specific policies on users, groups and machines which are members of the domain. One approach in this environment would be to impose a policy that would eliminate the "disconnect" option from the Remote Desktop client. You can also force automatic logoff in the domain users TS settings. I'm not saying that having a DOMAIN structure is the answer to all of your problems - just that it would give you FAR more flexibility and control over what your users can and cannot do.

The ideal solution in your environment would to find a way to configure terminal services to run a "logoff" script when a session is "disconnected”. This would cleanly close all running applications, mappings, etc, logoff the user and remove the session from the server.

Question - have you restricted each user to ONE Terminal services session? See: http://support.microsoft.com/?kbid=302883
If users are allowed to open multiple, simultaneous sessions under the same account, this can quickly eat up resources on the server - especially if they're NOT logging off properly.

Another random thought is that in the absence of a DOMAIN, you might be able to make policy/configurations on the end-user's PCs to impose "disconnect" restrictions in their Remote Desktop Client.
Another solution I've seen discussed out there is installing a special screen saver, which after inactivity, performs a LOGOFF from the TS session. Such a screensaver would have to be installed and configured on the user's TS profile - NOT on their local PC.

I know this is a lot of information to throw at you. I realize that if the lack of user compliance is the sole cause of this problem, solving it is going to involve some creative, automated solution which forces or automatically executes compliance. I'm still not ruling out some TS server setting or software issue as playing a part in this problem. I'm also concerned that those mapped PRN connections as well as having your account program running and logged to sessions which are being forcefully terminate might be further mucking up this issue. I also don't believe that switching over to a Domain environment, a rather involved, complicated and costly process - is the end-all be-all solution to your problems.

I think that with a lot of research along, step-by-step documented changes and troubleshooting are going to eventually bring about a more stable and workable solution to your TS woes. In a production environment like yours, this is not easy considering the end-users ongoing need to have access to your server. There's a lot of good information and advice out there - but don't consider ANY of this advice as Gospel. Microsoft is probably the most reliable source of information. Solutions and advice found on open user forums should be taken for what it's worth. Avoid purchasing, downloading or installing ANY third-party utilities, scripts or programs that offer a solution without careful research as to the legitimacy of the author/vendor, feedback from others who have used such a solution, a thorough virus scan of the download and a known way of backing up such a solution if it doesn't work - this advice is exponentially important when you're dealing with a mission critical application server. ALWAYS perform FULL backups of your server before making any major changes!

This is probably a redundant question - but are your users on a LAN environment connected directly to your Server? Is there any remote access available to your users? How many users are configured on your server. On average, how many simultaneous TS sessions do you have running on your server? What is the make/model of your server and how much memory is installed? You said that your server is hosted by a third-party company located elsewhere. How are your clients connected to your server? What kind of bandwidth do you have available from this offsite hosting company?

Again - WAY too many questions - but knowing more about the server platform and networking configuration might shed light on potential issues that I've not considered.

The following are links to tech-notes, discussions, etc which are relevant to your TS issue(s)
You may have to scroll through some of these pages to get to the relevant content.:

http://ts.veranoest.net/ts_faq_configurati…#KillDisconnect

http://technet2.microsoft.com/windowsserve…3.mspx?mfr=true

http://www.neowin.net/forum/index.php?showtopic=520738

http://www.hostmysite.com/support/dedicated/general/timeTS/

Write back and let me know if anything has changed and if my rather unorganized and overloaded post has provided any addition insight or ideas.

John

hahaa, Hi John! It was pretty organized and it wasn't too much to absorb, trust me. I read this for breakfast!! =) Everyone is already restricted to one session only. (thank goodness!) I decided not to terminate sessions. I'm going to have to spam my own people with log off instructions until they get it and I come up with a log off script. That screensaver is a great idea - must look into. I have a test server that I run everything on before placing it into a live environment. I was able to duplicate this issue on another server so at least that's going for me. The last thing I want is for total annihilation of a server just to fix a minor inconvenience in the grand scheme of things. The server is hosted in Florida, everyone is scattered throughout the U.S. so they're not on a local LAN. It's a Supermicro Pentium 4 CPU 3.00Ghz, 2.99 GHz, 2.00 GB of RAM with unlimited bandwidth, but if we go above 3 TB a month – we pay!! (this just never happens). I have about 30 users configured, but there are no more than 5-6 people logged on simultaneously. I have the licenses for up to 20 just in case but I never see it happen. All they do is log on, enter data, print out a record and log off. I will read the links you provided, thank you again for your help. –Penny

ZadeyTech,

Since your users are scattered all over the place, how are then connecting to the server? Is there some software or hardware VPN solution in place or are the connection directly through the Internet (no VPN)?

The server, storage and memory and licensing seems appropriate considering a user load of 5-6 concurrent sessions. It seems that you're probably going over this limit if the Terminal Services connections are being "disconnect" rather than removed by orderly logoff. You didn't mention what accounting software you're using. Knowing this would help.

Since all of the training in the world can't force end-user compliance with logging out versus disconnecting from their Remote Desktop / Terminal Services sessions, an obvious "fix" would be to completely ELIMINATE their ability to "disconnect".

See if you are able to go through these config changes on your server:

"Shut down options"

You can use the following two Group Policy settings, found in the Terminal Services folder under Computer Configuration/Administrative Templates/Windows Components, to remove items from the Start menu and Shut Down dialog box so that users cannot use certain methods to disconnect or log off from their session:

• Enable the Remove Windows Security item from the Start menu policy to prevent users from unintentionally logging off of Terminal Server.

• Enable the Remove Disconnect option from Shut Down dialog policy to prevent users from using this method to disconnect from Terminal Server.

If these are NOT settings available on your server than these are most likely options only available in Domain environments.

Check out this TechNet article:

http://technet2.microsoft.com/windowsserve…3.mspx?mfr=true

Hope this helps.

- John

"I'm going to have to spam my own people with log off instructions until they get it and I come up with a log off script." I have run into the same issue with clients not logging of like they should. Since they are not our employees (we are a hosting facility in Connecticut - they are in California), I decided to make SURE they knew about the problem. Create a document (.rtf so you can get colors and sizes - I like using a red !!ATTENTION!! ) that basically says Don't click the X, Logoff instead! This will greatly reduce issues with your login and pronters! Please the document on the root of primary drive (C:\ d:\, or whatever) and create a shortcut. Then go to the all users\startup folder and place the shortcut there Use a test account to make sure it works. What should happen is that the document opens up right in front of them with big letters telling them what to do. Leave it there for couple, then take it down. If they start slipping again, put it back up. This process is also a good to let them know about scheduled work for the server, etc. No need to worry about email addresses, or worrying about the end users getting the message!