[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 647
  • Last Modified:

Domain logon script when users logon with local accounts

Our network contains two Windows 2003 domain controllers and a Windows 2003 member server running Exchange. Our small group of workstations are all Windows XP Pro, which users log onto using local user accounts. They can then access shares on the servers based on AD group membership or individually assigned ACLs. I have tried to use GPO to control a logon script that records user information on the server but I can only get it to work if the user logs on with a domain account. Scripts assigned through domain profiles don't work either. Could it be that cached credentials are being used to establish connections with the server so netlogon doesn't really occur every time a user logs onto his local workstation? Is there a way around this?
0
ru-rd
Asked:
ru-rd
  • 4
3 Solutions
 
IanThCommented:
0
 
ru-rdAuthor Commented:
This would work. I would have to log on as Administrator on each workstation and set this up for each local user. I was hoping to be able to do it through GPO so I could take advantage of the logoff feature also.
0
 
ashutoshsapreCommented:
For the local account you can use gpedit.msc to add the logon script. You will have to add the script manually to all the computers though.
But if you have setup a domain then why are the users logging in with local accounts? Why not use domain accounts?
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
ru-rdAuthor Commented:
Gpedit.msc on the local machine should allow me to take advantage of assigning both logon and logoff scripts. However it doesn't seem to work. As the local Administrator, I used gpedit to copy the login.bat file to the %systemroot%\System32\GroupPolicy\User\Scripts\Logon folder, then ran gpupdate /force from a command prompt. Logged on as a local user and checked the shared server folder to see if the user information got logged. It didn't. I know it's not a permissions issue because when I ran the login.bat file manually it worked perfectly.
0
 
ru-rdAuthor Commented:
I found the problem! The Microsoft knowledge base article 315245 that IanTh pointed me to says the default location for the logon scripts is %SystemRoot%\System32\Repl\Import\Scripts. My XP machines didn't have this folder, and besides, this article describes how to assign a logon script to a profile for a local user's account. I wanted a way to use GPO, so I thought the article didn't apply. Gpedit on the local machine as ashutoshsapre recommended seemed like it should work but it didn't.
When I revisited the MS article I noticed "For a Microsoft Windows 2000 version of this article, see 258286" and I realized these XP machines had been upgraded from W2k so maybe that's why I couldn't find the described default folder. In the W2k version of the article it clearly states that the default folder is not created on a new installation of Windows. Therefore, the %SystemRoot%\System32\Repl\Imports\Scripts folder must be created and shared out with the share name netlogon.
This gave me an idea! Instead of creating that specific folder I shared the %SystemRoot%\System32\GroupPolicy\User\Scripts\Logon folder, which was the default folder according to gpedit on my machines, and named it "netlogon". Now everything works!
0
 
ru-rdAuthor Commented:
Others comments gave me clues to track down the final solution which I have posted to clarify the steps taken to complete the resolution.
0

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now