j_powers
asked on
Login.bat script will not run on Terminal Servers
Hey everyone. We have an interesting situation that I am not figuring out here. We run 9 Windows 2003 servers on the domain. Servers 6, 7 and 8 are Terminal Servers (Runing Citrix). The Active Directory sets 2 things - mapping the Home Directory (H:) through the user profile and running the Login.bat script which creates a J: drive.
Up until the other day there have been no problems. Both drives map. Now, if I log into the server, the J: drive doesn't map. The H: drive maps fine.
There was some white papers where it talked about certain registry entries and services that needed to be installed and running. The servers look like they're correct. Yet if I log into 6, 7 or 8, it still does not map the J: drive.
The entry in the Login.bat file is:
Net use j: \\Domain location\files
We have altered the bat file to disconnect the drive and reconnect and even run with persistance, but the result does not change. J: will still not map.Since the tech info suggested a service not running, we decided to reboot the three machines. No change.
Any other thoughts on this? If I log onto any other machine (server or workstation) the drive maps. If I type in the unc, it will go to the location. If I manually map the drive, it will be there.
Up until the other day there have been no problems. Both drives map. Now, if I log into the server, the J: drive doesn't map. The H: drive maps fine.
There was some white papers where it talked about certain registry entries and services that needed to be installed and running. The servers look like they're correct. Yet if I log into 6, 7 or 8, it still does not map the J: drive.
The entry in the Login.bat file is:
Net use j: \\Domain location\files
We have altered the bat file to disconnect the drive and reconnect and even run with persistance, but the result does not change. J: will still not map.Since the tech info suggested a service not running, we decided to reboot the three machines. No change.
Any other thoughts on this? If I log onto any other machine (server or workstation) the drive maps. If I type in the unc, it will go to the location. If I manually map the drive, it will be there.
Try this:
Create a new login script called logtest.bat and place it in the %logonserver%\folder\ location
Add the following syntax to logtest.bat:
%logonserver%\folder\login .bat >> %logonserver%\folder\%user name%Login .txt 2>&1
Next assign this script to a test terminal server user (generally one of the IT guys)
This will redirect all output from the original login script into a text file (including errors!) for evaluation. Please post the results here.
Create a new login script called logtest.bat and place it in the %logonserver%\folder\ location
Add the following syntax to logtest.bat:
%logonserver%\folder\login
Next assign this script to a test terminal server user (generally one of the IT guys)
This will redirect all output from the original login script into a text file (including errors!) for evaluation. Please post the results here.
Also wondering what happens if you add:
Net use j: \\Domain location\files
to the first line of the usrlogon.cmd located in the c:\windows\system32 directory. This script kicks off every time someone logs into the terminal server. Let me know if this manages to map the drive.
Hope this helps
Crow
Net use j: \\Domain location\files
to the first line of the usrlogon.cmd located in the c:\windows\system32 directory. This script kicks off every time someone logs into the terminal server. Let me know if this manages to map the drive.
Hope this helps
Crow
ASKER
The logtest.bat script does not come back with any errors.
I put the reference in the usrlogon.cmd file, and yes, it does kick off and map the J: drive, as well as any other drive in the script.
This is a perfect workaround, but not a long term issue. GPO should be controlling the file.
I put the reference in the usrlogon.cmd file, and yes, it does kick off and map the J: drive, as well as any other drive in the script.
This is a perfect workaround, but not a long term issue. GPO should be controlling the file.
Can you do the following at the command line:
gpresult > c:\gpresult.txt
Please post the results here
gpresult > c:\gpresult.txt
Please post the results here
ASKER
I am guessing you are looking for this part of the txt file:
Applied Group Policy Objects
-------------------------- ---
CTX Prod Policy
Local Group Policy
The following GPOs were not applied because they were filtered out
-------------------------- ---------- ---------- ---------- ---------- -
Local Group Policy
Filtering: Not Applied (Empty)
CTX Prod Policy
Filtering: Denied (Security)
Applied Group Policy Objects
--------------------------
CTX Prod Policy
Local Group Policy
The following GPOs were not applied because they were filtered out
--------------------------
Local Group Policy
Filtering: Not Applied (Empty)
CTX Prod Policy
Filtering: Denied (Security)
Which policy delivers the login script (It appears they are both being filtered)
ASKER
The CTX Prod Policy is in the folder in question. It works like this:
Domain
(Local Group Policy)
Citrix
(Blocking Domain Policies)
DEV
(No Policies)
PROD
(CTX Prod Policy)
The way it's set up is the way it's suggested to set up in several docs.
Domain
(Local Group Policy)
Citrix
(Blocking Domain Policies)
DEV
(No Policies)
PROD
(CTX Prod Policy)
The way it's set up is the way it's suggested to set up in several docs.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK. Sorry on the wait. Other issues had to come first. NEWay - here is the security of the profile CTX Prod Policy:
Authenticated Users - Read(From Security Filtering)
Domain Admins - Edit Settings, delete, modify security
Enterprise Admins - Edit Settings, delete, modify security
Enterprise Domain Controllers - Read
System - Edit Settings, delete, modify security
Authenticated Users are the only ones that have the 'apply group policy' permission in this GPO
Here is the hierarchy:
Forest
-Domains
--Local Domain (Default Policies in place)
---Computers
----Servers (Server Policy)
-----Citrix (Block Inheritance)
------Prod (CTX Prod Policy)
Authenticated Users - Read(From Security Filtering)
Domain Admins - Edit Settings, delete, modify security
Enterprise Admins - Edit Settings, delete, modify security
Enterprise Domain Controllers - Read
System - Edit Settings, delete, modify security
Authenticated Users are the only ones that have the 'apply group policy' permission in this GPO
Here is the hierarchy:
Forest
-Domains
--Local Domain (Default Policies in place)
---Computers
----Servers (Server Policy)
-----Citrix (Block Inheritance)
------Prod (CTX Prod Policy)
ASKER
I redid the permissions following a tech sheet I found. Once I did that, GPO started working without problem - well, at least not THAT problem. I cleaned up the errant policies for the container and it is now functioning correctly.
Thanks.
Thanks.
ASKER