The following is a collection of three real world administration problems and how they were solved.
Application failure – Service account password gets out of sync randomly
Problem: On every reboot or restart of the XYZ service -- or at some random point in the day -- the application using the XYZ service would fail with Access Denied. A workaround solution involved resetting the password on the service account, then making sure the password set in the service matched the service account's password in the Users and Computers snap-in. This would fix the problem until another reboot or when some amount of time had gone by.
Analysis: In this case, an admin had incorrectly enabled a Group Policy user right called "Log on as Service" and entered a user name in the list. This username was not that of the XYZ service account. As shown in Figure 1, you can either specify no users/groups or any number of users and groups. Note that if there is nothing in the list, then it is wide open and applies to all users.
If you make any entry at all in the list, the right is restricted to only users/groups in that list. As soon as the admin added that user and the policy was refreshed, only that account could log on as a service, excluding the XYZ service account. Thus, it prevented the XYZ service account from logging on as a service. Changing the password reset the account and got around the problem until the next GPO refresh.
Remember that on a workstation, the GPO is refreshed every 16 hours with no changes to Group Policy, so setting the password manually would work until the GPO was refreshed, making it seem random.
Solution: The solution was to either remove all users and groups from the Log On As A Service right or to add the XYZ service account to the list. Of course, this applies in general to service accounts.
Can't run more than 55 batch jobs from Task Scheduler
Problem: Administrator claims that when using the Task Scheduler on Windows Server 2003 SP2, he can only start 55 jobs under the LocalSystem account. He can, however, start more jobs under the context of a domain account.
Analysis: It turns out that he could schedule more jobs but they wouldn't run. This affected all servers.
Solution: We started by looking for a possible resource issue or something peculiar to the environment (because it couldn't be reproduced in our lab). The cause turned out to be lack of memory. Each of these jobs consumed some amount of memory. When it ran out, the job just wouldn't run, even though there was no event or error pop-up. We confirmed this by running a simple BAT file that opened a CMD prompt. The admins could then run more than 55 jobs. We also found that there was nothing magic about the number 55. It was just at that point where they ran out of memory to run the app. The solution, of course, is to add more memory (or don't run so many apps).
RunAs doesn't return user properties
Problem: Logged in as the Administrator account, a person opens the Users and Computers console. He then uses a "Saved Query" that was built to search for a user. Double-clicking on any one of the users causes the user properties window to appear. However, when using the RunAs command or another domain user -- including a domain admin account – to do this, the user properties don't show up.
Solution: In Group Policy, we enabled the following: User Configuration\Administrative Templates\Windows Components\Windows Explorer\ "Remove Windows explorer default "Context Menu." According to the Explain tab on this setting, enabling it disables right-clicks for menus (which displays properties). The admin account can't be blocked from anything but this blocked domain. Disabling the setting fixed the problem.
ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.