One piece of the puzzle is that PowerShell remains open if you do it the way I have it setup right now.  If the user closes that PowerShell window, then the monitor process will not close Outlook when the user exits the LOB app.  In order to mitigate this issue somewhat, I wanted to start PowerShell minimized.  The way to do this is:

powershell -WindowStyle Minimized .\ScriptToRun.ps1

Re: Unable to login using RDP or ICA after installing XenApp 6
Posted: Mar 31, 2010 5:27 PM   in response to: Aref Mukred

Correct

4 users found this post useful

Hi Aref -
Can you please try the following ?
1. Open Delivery Services Console
2. Edit the unfiltered user policy | ICA
3. Set the policy for Desktop Launches to Allowed
This policy applies to XenApp 6.0 and Allows or prevents non-administrative users to connect to a desktop session on the server.
When allowed, non-administrative users can connect. By default, non-administrative users cannot connect to desktop sessions.
Thanks
Ramesh

Citrix Forums : Unable to login using RDP or ICA after …

The answer above will get you there, but as my teachers used to tell me all the time, he needs to “show his work”:

I created an answer file and when I run Sysprep I get a popup that says:  A fatal error occurred while trying to sysprep the machine.

Hmm..  so I look at the logs and here is what I find:

2010-06-03 10:42:33, Error      [0x0f0085] SYSPRP LaunchDll:Could not load DLL drmv2clt.dll[gle=0x0000007e]
2010-06-03 10:42:33, Error      [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 126[gle=0x0000007e]
2010-06-03 10:42:33, Error      [0x0f00a8] SYSPRP WinMain:Hit failure while processing sysprep cleanup providers; hr = 0x8007007e[gle=0x0000007e]

I found lots of references to Windows Media Player, and that you can’t have sharing enabled.  Not a problem on this machine.  Not any help either. 

I did find this article helpful: http://myit4u.wordpress.com/2010/03/17/launchdll-could-not-load-dll-drmv2clt-dll/

Guess what?! Those aren’t shown in on a Windows Server 2008! Our workaround was to install the Desktop Experience feature on the server.

I added the “Desktop Experience” feature did the sysprep and then uninstalled it on each of the new machines.  Rather a pain, but I didn’t have a lot of time to work on figuring out a better answer.

One of the sets doesn’t have this error, but wouldn’t because they are physical servers.  They have been in production a long time, and we have plans to virtualize them. 

The second set doesn’t get the errors, but it is fewer servers and fewer users.

The third set:

• is virtual
• runs on 2008 R2 Hyper-V
• has more servers (6 as opposed to 4 or 5 for the other two)
• supports more users and more users per server (averages around 20 users per server during business hours)

Around November, we started upgrading our hosts from 2008 to 2008 R2.  The problems have been getting progressively worse peaking in the last 2 months.  Our last 2008 host was converted in March. 

After some event log review, we were able to correlate some of the issues to the following error in the event log:

Event Type:    Warning
Event Source:    netvsc
Event Category:    None
Event ID:    5
Date:        4/19/2010
Time:        3:49:53 PM
User:        N/A
Computer:    <ServerNameChangedToProtectTheGuilty>
Description:
The miniport ‘Microsoft Virtual Machine Bus Network Adapter #4′ hung.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00 00 00 00 02 00 52 00   ……R.
0008: 00 00 00 00 05 00 00 80   …….€
0010: 00 00 00 00 00 00 00 00   ……..
0018: 00 00 00 00 00 00 00 00   ……..
0020: 00 00 00 00 00 00 00 00   ……..

and right behind that would be this message:

Event Type:    Information
Event Source:    netvsc
Event Category:    None
Event ID:    4
Date:        4/19/2010
Time:        3:49:53 PM
User:        N/A
Computer:    <ServerNameChangedToProtectTheGuilty>
Description:
The miniport ‘Microsoft Virtual Machine Bus Network Adapter #4′ reset.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00 00 00 00 02 00 52 00   ……R.
0008: 00 00 00 00 04 00 00 40   …….@
0010: 00 00 00 00 00 00 00 00   ……..
0018: 00 00 00 00 00 00 00 00   ……..
0020: 00 00 00 00 00 00 00 00   ……..

After doing a bit of searching and getting a lot of nothing, and doing some on site troubleshooting without much luck, I finally broke down and called Microsoft.  I spent a day e-mailing back and forth with someone who was suggesting that I try all the things that I had already tried, so I contacted our TAM and had the case escalated. 

The technician then informed me that there was an internal hotfix that had not been fully tested yet, that related to my issue.  It seems that in 2008 R2 Hyper-V guests running Server 2003, the network adapter will hang and then reset under heavy load.  The hotfix has to be applied to the host and then the integration services on the guest have to be updated.  In my environment, when I updated, I had to remove the integration services from the guest before the updated NIC driver would install.  I reported this behavior to the technician I was working with, but he said that he couldn’t reproduce that particular problem and that he had no issues updating his test environment.

It is my understanding that the hotfix will be released under KB981836.  When you install this, it changes the integration services version from 6.1.7600.16385 to 6.1.7600.20683.  You can see this if you look at the driver version on the guest NIC.

Now that the problem was understood, Microsoft and Citrix brainstormed on workarounds customers could apply while Citrix worked on an update to the ICA Client that would prevent the sharing violation. One workaround was to disable application prefetching and another was to write a logoff script that deletes the Ssonsvr.exe prefetch files. Citrix published the workarounds in this Citrix Knowledge Base article and Microsoft in this Microsoft Knowledge Base article. The update to the ICA Client, which was made available a few days later, changed the network provider DLL to 10 seconds after Ssonsvr.exe launches before returning control to Mpnotify.exe. Because Winlogon waits for Mpnotify to exit before logging on a user, the Logical Prefetcher won’t associate Winlogon’s accesses of the user’s hive with Ssonsvr.exe’s startup.

Mark’s Blog : The Case of the Temporary Registry Profiles