Troubleshooting Group Policies, part 4

By Brien M. Posey | Jun 7, 2001 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/780541/Troubleshooting-Group-Policies-part-4.htm

So far in this series, we've provided you with some general methods for troubleshooting group policies and best practices for implementing group policy objects. This time out, I'll continue the discussion by explaining how to fix some common group policy related problems.

Some of the more common group policy related problems involve not being able to open the group policy object. If an administrator has trouble opening a group policy object, the problem could be that the administrator has insufficient permissions to it. Bear in mind that if an administrator logs on to a machine locally, they'll have local administrative privileges, and will probably have no problem editing the local group policy. However, this doesn't necessarily mean that the same administrator will have permissions to edit a group policy object at the domain level. Likewise, even if an administrator has permissions to edit a group policy object at the domain level, that doesn't guarantee that the administrator will be able to edit group policy objects that exist in a remote domain.

If an administrator is having problems editing a group policy object, then make sure that the administrator is a member of a security group that has permission to access the object. Remember that Administrators must have read and write permissions to a group policy object before Windows will even allow them to open the object within the Group Policy snap in.

Another possibility that may be causing the problem is that the network is configured incorrectly. For example, suppose that machines on your network are configured to use two different DNS servers. If those servers have no knowledge of each other then they will have trouble communicating with each other at the Active Directory level. Active Directory depends on DNS, and a situation like this would fulfill that requirement, but unless all of your DNS servers have knowledge of each other then there's no way for some of your systems to be able to access some of the Active Directory objects, in this case group policy objects.

Still another possibility is that Windows may no longer see a machine as being a part of a domain. In Windows 2000, each machine has a computer password. Occasionally, for what ever reason, these passwords sometimes become invalid, especially after a restore. If you can't seem to access a domain security policy from a particular machine, try resetting the machine's password. To do so, open a command prompt window and enter the following command:
Please note: This should be one line.

NETDOM RESETPWD /SERVER:servername /USERD:domainADMINISTRATOR /PASSWORDD:*

Entering this command will make communications between the machine and the other domain controller functional once again. Although Windows won't give you a warning, you'll have to reboot the machine before the reset will take effect.

As you can see, proper network configuration and permissions are essential to being able to work with group policy objects. In Part 5, I'll start discussing some reasons why group policy settings may not be applied correctly or at all.

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.