Se il profilo utente non viene creato in maniera completa ( per intenderci coma quando si esegue un log-on interattivo su una macchina) può succedere che le policy di domino non vengano applicate in parte.
Ovviamente questo può provocare funzionamenti imprevedibili o non coerenti.
Per ovviare al problema seguire questa guida:
Some
applications that rely on the Explorer.exe file may run in the TS RemoteApp
session if you add the Runonce.exe file to a user’s logon script. To do this,
follow these steps:
1.
In the server GPMC, click Local Computer Policy,
click User Configuration, and then click Windows Settings.
2.
Click Scripts (Logon/Logoff), and then
double-click Logon.
3.
Click Add.
4.
In the Script name box, type runonce.exe.
5.
In the Script parameters box, type /AlternateShellStartup.
Click OK
two times.
Seguno i link agli articoli MS:
----------------------
An application does not start in a Windows Server 2008 Terminal Services RemoteApp session
Article ID: 951048 - View products that this article applies to.
On This Page
SYMPTOMS
Consider the following scenario. You log on to a Windows Server 2008 Terminal Services RemoteApp (TS RemoteApp) session. The TS RemoteApp session includes the startup applications and the Run registry entry or the RunOnce registry entry. Then, you try to start an application in the TS RemoteApp session. In this scenario, the application does not start.
Back to the top
CAUSE
This issue occurs because you try to start an application that relies on the Explorer.exe file. By design, the TS RemoteApp session implements limited functionality. For example, the TS RemoteApp session does not process the following items:
- The Run registry entry
- The RunOnce registry entry
- The startup applications
WORKAROUND
To work around this issue, use one of the following methods.
To specify the startup applications as a part of a user's logon settings, follow these steps:
Method 1: Run the startup applications as a part of a user's logon settings
To run the startup applications in the TS RemoteApp session, you can specify the startup applications as a part of a user's logon settings in Group Policy. Because Group Policy controls these settings, any startup application that you specify runs as expected when the user logs on.To specify the startup applications as a part of a user's logon settings, follow these steps:
- In the server Group Policy Management Console (GPMC), click Local Computer Policy, click Computer Configuration, and then click Administrative Templates.
- Click System, double-click Logon and then double-click Run these programs at user logon.
- In the Run these programs at user logon Properties dialog box, click Enable.
- Click Show, and then click Add.
- Type the name of the startup application.
Note Unless the startup application is located in the %SystemRoot% folder, you must specify the fully qualified path of the file. - Click OK.
Method 2: Start the Runonce.exe file together with the /AlternateShellStartup switch
Some applications that rely on the Explorer.exe file may run in the TS RemoteApp session if you add the Runonce.exe file to a user’s logon script. To do this, follow these steps:- In the server GPMC, click Local Computer Policy, click User Configuration, and then click Windows Settings.
- Click Scripts (Logon/Logoff), and then double-click Logon.
- Click Add.
- In the Script name box, type runonce.exe.
- In the Script parameters box, type /AlternateShellStartup.
- Click OK two times.
Properties
Article ID: 951048 - Last Review: October 7, 2010 - Revision: 3.0
APPLIES TO
- Windows Server 2008 Datacenter
- Windows Server 2008 Enterprise
- Windows Server 2008 Standard
- Windows Server 2008 for Itanium-Based Systems
Keywords: | kbstartup kbstartprogram kblogin kbexpertiseinter kbtshoot kbprb KB951048------ |
------------------------------------------
How-to Make Group Policy Work with Citrix Published Applications
Posted on May 11, 2011 10:19 AM
As part of a Citrix environment overhaul, another network engineer and I discovered a very frustrating limitation of using group policy with Citrix published applications. The problem centers around the inability to apply IE group policy settings using loopback mode processing. I'll warn you ahead of time, there are lots of details so hang with me....and remember this is all going to converge at the application of group policy. Here is what we found...
When a user with an empty roaming profile (new user) has their profile created as the result of running a published application, the user portion of the registry hive (ntuser.dat) is not created in its entirety. The users' hive can be loaded and a number of noticeable differences exist between it and the default user registry hive. If the user profile is created by logging on locally (console), via RDP to the same machine, or via Citrix published desktop on the same machine, the profile that is created is complete. I was unable to find any noticeable differences between the default user registry hive and that of the newly created roaming user profile when the profile was created in this way. Additionally, once an incomplete profile had been created via published application session, the profile could NOT be "fixed" by logging on via RDP or published desktop. Once the registry hive was created in an incomplete fashion, it seemed to be affected from then on. So why are we talking profiles...I thought this was about group policy? Well, it is...I'm getting there.
We found that users running published applications did not have group policy correctly applied. We were trying to set policies on Internet Explorer using Internet Control Panel settings in the user portion of the GPO. Specifically, IE security zone settings such as trusted and intranet sites would not apply. We also noticed that each security zone seemed to be locked. In the Security tab of the Internet Options dialog box, all the icons were the same....blue IE symbol with a lock next to it. The "Sites" button and the "Custom Level" button were also grayed out. So, here is the where the profile problem merges with the group policy problem. I found that by manually exporting certain keys from the default user profile registry hive under \Software\Microsoft\Windows\CurrentVersion\Internet Settings\ and importing them into in a incomplete user registry hive, I could fix the problem. That is, once the keys existed in the user registry hive that pertained to the settings I was trying to set via group policy, the policy was applied correctly...no issues. Makes sense right....if the group policy is setting registry keys in order to apply certain policies, it’s not going to work if the keys don't exist in the first place.
So things have come full circle. Group policy isn't working because the user profile is messed up. So why is the user profile not getting created correctly? Well, this is actually a Microsoft problem -->http://support.microsoft.com/kb/899270. And the script they provide doesn’t work…we tried it. Actually, there is more to the problem than that, but here is a summary of the information that we gathered. By design, Citrix published applications, remote applications in Windows 2008, and the "start this application on connection" functionality of RDP (mstsc.exe) running against Windows 2003 servers implement limited logon functionality so that the session footprint is smaller than a normal desktop session. Part of the "limited functionality" is that the user session does not start explorer.exe. So, any application that depends wholly or in part on explorer.exe could have issues. Some of the important pieces of functionality that explorer.exe implements are the following:
- The run registry entry
- The RunOne registry entry
- Startup applications
If you have ever noticed the small gray box that is displayed the first time you log on as a new user, you have seen the effects of explorer.exe running at session logon. It goes by fast, but it says something like "applying internet explorer customizations", "setting up windows media player..."...stuff like that. That little box is normally initiated by explorer.exe. It is called runonce.exe. What we found was that if we initiated runonce.exe in a logon script, the user was created correctly when running published application; thus, group policy was applied correctly as well. Testing also showed that this process could also fix a previously created broken user registry hive (ntuser.dat). All we had to do is add the following to our logon.bat file
start /MIN %windir%\system32\runonce.exe /AlternateShellStartup
Citrix has documented this problem in a support article (http://support.citrix.com/article/CTX104374) and they refer back to the previous MS KB listed above. Numerous forums threads exist on this issue and we were unable to find a resolution elsewhere that did not include scripting registry imports to the user profile at logon. This workaround seems to be a more flexible and reliable
Nessun commento:
Posta un commento
Lascia qui il tuo commento.