This is taken from the Citrix Knowledge base and can be found at: http://ctxex10.citrix.com/texpert.nsf/9e80f371ea46c82a852566710066ab6c/a12c1fff5dcbb86c85256893006c3282?OpenDocument
Product: All Ver. All Build All:English US
Category: Application Integration ; Application
Synopsis:
Frequent calls indicate that regular User or Anonymous accounts fail to run an application within a Citrix ICA session. The ICA session can be a published application or a published desktop within a Citrix Server Farm or directly on the server. If the User accounts are logged on at the console, they fail to execute the application. For anonymous published applications that are failing, typically a User account also fails. Making the User class part of the local and/or Domain Administrators group enables the User account to successfully execute the application. This often means that there is a file rights issue on the server(s) in question. This technique can also resolve logon errors.
Details:
Please follow the steps below to resolve these types of issues:
1. Verify what happens with the particular User account at the server console. If the error appears at the console level, the problem is most likely with the application itself. Ensure the error can be corrected on the console before continuing.
2. Add the User to the local and/or Domain Administrator group. Retest the account at the console.
If the application executes, move to Step 3.
If the application still fails to execute, it is more likely an application configuration problem.
3. Log on to the server as an administrator.
If the Citrix server giving the error is a domain controller, only a Domain account can log on (there are no local accounts).
If the Citrix server giving the error is a standalone server, log on to the server as a local administrator.
If the Citrix server giving the error is a member server in a domain, select the local server name in the drop down box for the server at the Logon prompt.
4. Enable auditing in User Manager for Domains. From the Policies Menu choose Audit. Typically it is enough to select File and Object Access for failure.
5. Audit the directory of your choice; %systemroot%\system32 is a good start and is most commonly the problem. Begin by right clicking the directory, selecting Properties, Security, Auditing.
Add the name of the user to be audited. Check both the Replace Auditing on Subdirectories and Replace Auditing on Existing Files boxes. Also, check off all failures to be audited. Press OK.
6. If you receive an error message that the Pagefile.sys cannot be audited, press OK.
7. You may receive one of the following error messages when setting up auditing on the directory of choice:
"The current Audit Policy doesn`t have auditing turned on. Ask an Administrator to use User Manager to turn on auditing."
If this error is displayed, ensure that auditing is enabled for the local SAM database via the domain SAM in User Manager for Domains."
8. Connect to the server desktop as an administrator, open the Event Viewer, and select the Security Log.
9. With a second session to the server desktop, make a "duplicate" copy of a custom ICA connection if needed. Connect with the name of the user you are auditing.
10. When the user has a desktop, delete any entries in the Security Log.
11. Execute the application and acknowledge any error messages.
12. Recheck the Security Log for any new entries. Choose View and then Refresh if needed.
13. Double-click each logged entry (there only should be a few). Note the file path and subsequent dll and exe files. Check the permissions on each file. Locate the file to which the user does not have access and is causing the failure.
Adding the domain users group with Read permissions usually resolves the issue.
NOTE: These steps may need to be repeated for different applications or subsequent errors within the same application.
While this is not quite Citrix or Terminal Server specific item an virus on a TS could cause serious problems for all users.
After the recent ILOVEYOU trojan email worm I came up with the following BRILLIANT(if I do say so myself) solution. I have caught and deleted EVERY email attachment virus on my own email I have gotten(and I have received several) since implementing it.
Here is an excellent idea I came up with yesterday to make users THINK before opening attachments. This is what you do:
Create a folder in your email program called "Caution-Attach!" and then create a rule that ANY incoming message with an attachment go to the "Caution-Attach!" folder.
Depending on your email program you may not be able to create rules but Outlook and Outlook Express both allow you create a rule on attachments under the tools menu. (Check your help files if you do not know how to create a message rule.)
Users can then switch their preview pane view if they need to before they open the Caution-Attach! folder to prevent them from accidentally being open and just delete any suspect emails first. They can then move any attachments they need out of this folder.
You also want to make users aware and tell them to remember(and the word caution in the folder name should help) that anytime they open anything from this folder that it has the potential to have a virus and to immediately delete ANY suspicious files that end in .exe, bat, vbs etc. without opening them from this folder.
This would be a good practice to teach from the start AND you would physically have to think to GO to the Caution-Attach! folder and be cognizant that the emails you are opening have attachments.
I implemented this on my home email and I guarantee you that I will never be caught off guard again.
You should also have a good virus email firewall on your Exchange or mail server. We now use ScanMail which has many robust features. When we first installed it, it found 5 virus attachments in our mail store and repaired them that our original program we had Innoculate-It did not catch.
It has come to our attention that MetaFrame Administration is producing DrWatson errors upon opening after applying the updates from Microsoft Technet Article Q269214. What happened is that an old Microsoft Hotfix (Q147222) is being re-applied as a result of applying the updates from Q269214.
After you apply Q269214, please delete the following registry key, then reboot your server:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\Q147222
Update! (Note this did not work for me, I still suggest you use my original solution below)
The following information is from the Citrix Forum below it is our previous solutions.
Citrix Systems on 06/27 at 04:39 PM MetaFrame
TSE SP 6/MF 1.8 SP 1 and ICA Browser update. Please read...
Attention! If you are experiencing issues with the ICA Browser failing, or overall network performance degradation after applying TSE SP4, 5, or 6 and MF 1.8 SP1, please read on...
We have positive feedback that the following registry change recommended by Microsoft and documented in the below Technet Article, stops the main issue of the ICA browser hanging after applying MS TSE SP 6. Please try the following.
---------------------------------------------------------------------------- -------------------------------------------------------------
WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
For information about how to edit the registry, view the "Changing Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT or Windows 2000, you should also update your Emergency Repair Disk (ERD).
---------------------------------------------------------------------------- ----------------------------------------------------------------
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters On the Edit menu, click Add Value, and then add the following registry value:
Value Name: FileSystemControlFilter
Data Type: REG_DWORD
Set this value to 0, then reboot your server.
---------------------------------------------------------------------------- -----------------------------------------------------------------
CAUSE
A change was made to the Rdr.sys file in Windows NT 4.0 Service Pack 4 to fix a problem with a handle being invalidated when a dismount occurs. This may cause additional network traffic, which may degrade performance. The original value that this registry key was set to was 1.
This has been an ongoing problem with the ICAbrowser service we have noticed with Metaframe SP1 or TSE SP6.0. This is the solution I have come up with to resolve these problems. One thing you can do is in Citrix Server Administration go to the ICA browser tab and decrease the Master ICA browser Update Delay and and Refresh Interval values. I have decreased our Update delay to 2 and Refresh Interval to 10 on all of our servers with some success. If this doesn`t work try the following suggestions. First, you need to make sure that your server does not have Task Scheduler service installed for this solution to work. If it does you need to replace the service back to the AT service per the following FAQ item:How to get the AT Service back after IE installed Task Scheduler
I reccomend you do the follwoing:
Take a workstation and load TS/MF base installation and force it to be the Master browser and let the license run out. Browsing will still work. Making a machines sole function as a ica master browser is the best thing that has happened to our citrix environment and our network.
Install TS SP5 on the master browser machine and the latest Metaframe hotfix that contains ICAbrowser.exe that is the same on ALL your other machines and that is all. If you are running MF service pack one install SP1. DO NOT INSTALL INTERNET EXPLORER ON THIS MACHINE.
Be certain that the version of icabrowser.exe is the same on ALL of your servers or the server that has the newest version will try and take over as the master. IN OTHER WORDS IF YOU HAVE METAFRAME SP1 ON JUST ONE MACHINE IN THE FARM YOU SHOULD PUT IT ON ALL THE OTHERS! Keep the same version of icabrowser.exe on all your machines at all times to avoid confusion.
You rarely have to reboot the machine that is the master browser also since it is not really running any applications. One thing I have found is that if you have a nightly reboot, you must reboot your MB first and make sure it is up before rebooting the other machines in the farm or they do not always show up in the farm.
Now here is another tip. Use the soon command on all your machines to create a self rescheduling file stop and restart the browsing services every 4 hours:
==================
soon 14400 "%0"
net stop computer browser
Timeout.exe 3 net stop icabrowser
Timeout.exe 5
net start computer browser
Timeout.exe 3 net start icabrowser
You can use the autostrt.zip program and include this script in it to be sure this script is running after a reboot. See http://thethin.net/autoexnt.cfm for more information on how to use this utility. Download the soon command from here.... http://thethin.net/soon.zip get timeout.exe from the NT resource kit or MS site and is required to give the browser service time to shut down before the restart command fires off.
By performing all of the above procedure your icabrowser issues will be greatly reduced if not totally eliminated.
Here is a simple batch file that you can implement in your startup script that will do this. This script deletes all files and subdirectories in the temp directory:
===========================
echo y | Del c:\temp\*.* /S
rd c:\temp\ /s /q
md c:\temp
Cacls C:\TEMP /E /P EveryOne:F
===================
The | is the pipe command found above the \ key. The CACLs command ensures that everyone can write to your temp directory. Adjust the c: to your drive letter. You can run this file everytime at system startup if you download and install the autostrt utility from thethin.net to do it.
More info:
The batch file on rare occassions deletes the temp directory. This is the reason for line recreating it. If the directory already exists the command is ignored. It is not a risky thing to do since if there is no temp directory one is automatically created as soon as the first user logs in, problem being is that user is the one with full rights to it...thus the cacls command.
The CACLS command changes security on the Temp directory for everyone to have full access to it and was also my solution to the post sp4 problem of users not being able to write to their temp directories. It was supposedly fixed in SP4 and SP5 but wasn`t completely which is why it is a good idea to keep it in.
Windows NT system policies were created for when users log on to a domain account database. You can create a system policy for use when logging onto a local account database. If a user logs on to the local account database, the policy will be applied (to everyone, including Administrators). If they logon to a domain database, domain policies will be applied.
To create a local policy, log on locally as an Administror and create a NETLOGON share on the local computer at
%SystemRoot%\System32\Repl\Import\Scripts. Grant the Everyone group Read permission and the Administrators group full control on this share. In Poledit.exe, configure a simple policy to start with. Double-click Local Computer.
Double-click Network.
Double-click System Policies Update.
Click Remote Update to select it.
Click Automatic (Use Default Path) in the Update Mode box.
Click OK.
Save the policy as NTConfig.pol (it will be saved in the %SystemRoot%\System32\Repl\Import\Scripts folder).
Note: If you don`t want to create a NETLOGON share, choose Manual (Use Specific Path) in the Update Mode box and type the path into the Path for Manual Update dialog box. In this case, you can name your policy anything you wish.
Here is some info on where it is stored in the registry also
The Update registry key has value entries which control the application of System Policies. Edit:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Update
UpdateMode is a REG_DWORD with the data values:
0 - A policy file is not downloaded from a server and is not applied.
1 - NTconfig.pol is downloaded ( if present) from the NetLogon share of the %LogonServer% and applied.
2 - The UNC path of the policy file is read from NetworkPath and if present, downloaded and applied.
NetworkPath if a REG_SZ value that contains the full UNC path to the policy file. It is only used if UpdateMode is a 2. Example:
\\ServerName\ShareName\MyPolicy.pol
If you want to use NTconfig.pol locally on a machine that is part of a domain you can do the following...
You can set up Policies for the local account database.
Create a Netlogon share for in %SystemRoot%\System32\Repl\Import\Scripts with Read permissions for Everyone and Full Control for the Administrators group.
Use Poledit.exe and create your policy. Windows NT system policies were created for when users log on to a domain account database. You can create a system policy for use when logging onto a local account database. If a user logs on to the local account database, the policy will be applied (to everyone, including Administrators). If they logon to a domain database, domain policies will be applied. To create a local policy, log on locally as an Administror and create a NETLOGON share on the local computer at
%SystemRoot%\System32\Repl\Import\Scripts. Grant the Everyone group Read permission and the Administrators group full control on this share.
In Poledit.exe, configure a simple policy to start with.
Double-click Local Computer.
Double-click Network.
Double-click System Policies Update.
Click Remote Update to select it.
Click Automatic (Use Default Path) in the Update Mode box.
Click OK.
Save the policy as NTConfig.pol (it will be saved in the
%SystemRoot%\System32\Repl\Import\Scripts folder).
Note: If you don`t want to create a NETLOGON share, choose Manual (Use Specific Path) in the Update Mode box and type the path into the Path for Manual Update dialog box. In this case, you can name your policy anything you wish.
Double-click Local Computer, double-click Network, double-click System Policies Update, and then select Remote Update.
Click Automatic in the Update Mode box, and then click OK.
Save the policy to the Netlogon share as Ntconfig.pol.
NOTE: This will allow you to use both a local and a domain-wide system policy, depending on which user account database the user logs on to.
Microsoft Article Q259436describes the best way to do this.
|
This phenomenon occurs because there is an empty entry in the run key in the registry. Open regedt32.exe and navigate to:
Hkey_local_machine/Software/Microsoft/Windows/Current Version/Run
Check the entries in the right pane and if any of them do not have a value entered in them. Delete them. This will resolve your problem.
This is further documented in Microsoft Knowledgebase article Q170086