GPO's and Security Policies

I'm having some problems with our Group Policy Objects on our DC. I'm trying to set domain level security policies, but when I try to get into DC Security Policy I get the error "failed to open Group Policy Object". Did some googling, and an article directed me to gpotool.exe. I ran it, and here's what I got:

Quote:

---

C:\Program Files\Resource Kit>gpotool /verbose
Domain: HIFS
Validating DCs...
HPSERV.HIFS: down (sysvol only)
domcon.HIFS: down (sysvol only)
bakserv2.HIFS: down (sysvol only)
Error: DC list is empty

---

All three of those are indeed DCs.

So, I don't know much about this, beyond that sysvol being down is a really bad thing. Can you guys shed some light on this, and how I go about fixing it?

Any hints from your event logs?

Any services down?

try a google on domain replication. Use www.eventid.net and go through ALL event errors.

Hey Hey,

I'm not entirely sure, but didn't you post before about DNS problems? The only reason I ask is because this can be related to a DNS problem

Quote:

---

[i]Source: http://www.jsiinc.com/SUBM/tip6400/rh6484.htm[i]
When you open any Active Directory snap-in or tool, you receive a message similar to:

Failed to open the Group Policy Object.
Details: The specified network password is not correct.

This behavior will occur if the DNS settings on your computer are NOT properly configured:

01. Use Control Panel to double-click Network and Dial-up Connections.

02. Right-click Local Area Connection (or the name you have assigned to your internal network adapter) and press Properties.

03. Select Internet Protocol (TCP/IP) and press Properties.

04. Make sure that the IP address on the Preferred DNS server box points to the local DNS server. If this is NOT a Microsoft Windows 2000 (or greater) DNS server, it must be BIND 8.12 or later. If it is pointing to your ISP, implement DNS Forwarding. Alternately, you could point the Alternate DNS server to your ISP.

05. Press the Advanced button.

06. Select the DNS tab.

07. Make sure your local DNS server is listed first in the DNS server addresses, in order of use box.

08. Check the Append primary and connection specific DNS suffixes radial button and check the Append parent suffixes of the primary DNS suffix box.

09. Make sure the the DNS suffix for this connection box has your Active Directory domain name, like JSIINC.COM, and check the Register this connection's addresses in DNS box.

10. Press OK, OK, and OK.

---

also if you aren't getting the password details then

Quote:

---

Source: http://www.winnetmag.com/WindowsSecu...992/39992.html


Whenever I try to open a Group Policy Object (GPO) to view its security settings, I get the error Failed to open the Group Policy Object. You may not have appropriate rights. Details: The system cannot find the path specified. Why can't Windows find the GPO?

This error usually signifies a problem with DNS. To ensure that your DNS server is functioning correctly and isn't logging errors, check the DNS event log on your DNS servers and the Directory Service (DS) log on all your domain controllers (DCs).

If DNS is functioning correctly, the problem could be something more serious, such as a problem with your SYSVOL share or file replication on your DCs. A good way to check those and other problems with Group Policy is to use the Group Policy Verification Tool (gpotool.exe), which you can download from http://www.microsoft .com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp. At the command line, type

gpotool /verbose

---

It mentioned the gpotool that you used, but before that it mentioned checking DNS as does the other article.. have you checked your DNS over?

Peace,
HT

There are no errors in the DNS event log.

Quote:

---

Failed to open the Group Policy Object. You may not have appropriate rights. Details: The system cannot find the path specified. Why can't Windows find the GPO?

---

That's the message I'm getting, word for word.

Quote:

---

09. Make sure the the DNS suffix for this connection box has your Active Directory domain name, like JSIINC.COM, and check the Register this connection's addresses in DNS box.

---

This was the only thing not already set, so I set it to our domain properly. No change in results though.

Road -- No event errors related to DNS were present in any of the variou event logs.

just for checking:
the workstation where you are trying to admin AD is pointing to same DNS server that contains AD structure?

Right, it sure is.

so, after obvious...and your station has the same dns suffitx of AD servers too...

have you checked sysvol rights?

can you access dc admin console from that station? and create a object (any) on AD?

Ok, sysvol and its rights are what I'm wanting to learn about -- How do I go about looking into sysvol rights?

And actually, this isn't from a work station, but through the DC locally. I can go into the DC's control panel and on into Domain Security Policy and that's when I get the GPO error. So it's on the DNS server itself.

bad, bad dog
i thought you were accessing from a workstation...:)

since you have more than one DC server, you got the same error on all?

Heh heh, bark and stuff. ;)

Let's see, of the three DCs, only two have access to domain security settings, but both do indeed suffer the same error.

thats odd....
shall we go to basic troubleshooting?
get one of the servers (lets suppose its Server1)
go to DNS Server (that hold AD Structure) and see if A record is presented there
ipaddress A server1.addomain.com
check if ip adddress match if server1 ip address.
At server1 ip configuration:
be sure that domain name (dns property) is addomain.com (as you have defined on AD)

but is really odd.
a lot of things should not work too. not just snapin.

that message use to be that thing. You misconfigured AD server and it cant contact itself. dont blame me. its a microsoft idea...

Ah, but odd problems have a tendancy of finding me. ;)

Well, all that checks out ok, except for one minor discrepency -- the domain (named HIFS) does not have the ".com" suffix. So nowhere in the network do you see "HIFS.com", only "HIFS". In other words, all machine names are "NAME.HIFS" as opposed to "NAME.HIFS.COM".

I haven't thought that to be a big deal since it's been that way since the beginning, and has caused us no problems. However, I have read in MS articles in the past that lacking the ".com" can cause some communication problems. Could that be the culprit somehow? I doubt it since we've made it this far without it, but I'm open to anything.

I have been told about, but, like you, some AD structures that i have deployed use the same ideas as yours. The important thing is that AD domain name is connected to a DNS domain name (that use to be the same one) and servers domain name must match on that structure. When servers request AD (and other) functions, they locate those service thru DNS service (no more WINS - thanks GOD). If you have a discrepancy on that, you may experience some problems, such networks errors or lag.
When your saying that domain name is "HIFS" you are refering to AD domain name, right? that one you can see on AD snap in..

Yes, it is indeed so with AD snap in.

So I wasn't aware that there's a difference between DNS domain and AD domain. These are not necessarily one in the same? What's the difference?

my bad. i ve passed you a wrong idea.
____________________________________
When you install AD, you are asked for 2 names:
a) AD name, in the "dns" form - like abc.com <-- this name will be used to create a DNS zone, so AD NAME is EQUAL then DNS domain name
b) a nt domain like, for compatibility with old versions domains (NT Domains). Usually, if AD name is "abc.net", nt domain will be "abc". But it may be diferent
_______________________________________

Now, back to to subject. I was talking about "server" domain name. it can be slighty different from AD dns name. I.E. you can put all servers in a subdomain.

When u r acessing AD schema, all names are "resolved" thru DNS. Is that why i asked you about entried on DNS. If one is wrong, odd things happens
__________________________________________

Gotcha, I get it now. Well first then, for simplicity's sake we only have one domain for the entire office (we're only working within the range of 20 computers give or take, so the one general domain is sufficient). So everything, servers and workstations, is on the HIFS domain.

So second, I have been catching some DNS problems. I had a few workstations stop communicating with the others. For instance, one couldn't access the printer of another because access was denied. It took me a bit to figure out what was going on, but it turned out that the IP shown for the machine in DNS was different than the one shown as leased out to it in AD. Once I fixed that, it worked fine. There have been a few instances of that.

I believe I may have found something else. In DNS Forward Lookup Zone, Host (A) has an IP address that is inactive (does not respond to ping nor is assigned to any server/workstation). What should that be set to? The DNS server's IP perhaps?

/edit -- There are 8 other similar host files in there, all with different IPs. I'm kinda in foreign territory here, not sure what all of that means just yet.

/edit -- Discovered something that definately is messed up. As it turns out. A number of machines have one IP shown in DNS, and another shown in DHCP. I'm trying to fix those right now.

Make sure your machimes are set to dynamically update the DNS server and make sure the server is set to accept dynamic DNS updates. It sounds like some of them aren't. If you are using pre-Win2k you need to d/l an updater patch from M$, win2k & WinXP are able to do this natively.

Do you mean set each machine to have it's IP automatically configured rather than manually assigned? We do indeed have some that have automatically detected IPs and others that are configured manually.

The way you have described you problems in the past leads me to believe that your base problem is a DNS issue. IIRC you noticed last time that there was a discrepancy between the IP address issued to a machine and it's registration in the DNS system. You noted that fixing the DNS record fixed the issue. That makes me believe that some of your machines are either unable to dynamically update thier own DNS record or that the server isn't accepting dynamic updates to the DNS records. It seems to me that this issue may be related and it's something you need to investigate.

It's not an easy issue to troubleshoot but since it appears to be the root of the problem from where I sit it's definitely an alley I would "wander down"

Ok, got an update:

I'm convinced that, as Tig said, it's a DNS issue at the heart of the matter. Looks like there's a problem with File Replication Service, as I'm getting Event ID 13568 from NtFrs on the domain controller (one of the three DCs anyway).

To test out FRS, I saved a text file to the shared folder for the domain in the SYSVOL directory, then took off to lunch. Just came back, and it hasn't replicated to the other DCs yet.

So, how do you go about fixing replication issues?

//Edit -- I'm also reading something about accssing the Dfs snap in to enable or disable FRS. However, I see no such animal in Control Panel --> Administrative Tools. How do you get into Dfs Admin?

//Edit -- Found something else wierd. One of our main terminal servers is set to 192.168.1.93, which has to remain that way so others know what IP to connect to remotely. For some reason, however, DHCP from the DC has changed it to 192.168.1.26. How can that be?

Quote:

---

//Edit -- Found something else wierd. One of our main terminal servers is set to 192.168.1.93, which has to remain that way so others know what IP to connect to remotely. For some reason, however, DHCP from the DC has changed it to 192.168.1.26. How can that be?

---

Are you saying that you have your servers setup to get their IP through DHCP? You should never do that. Statically asign your IP addresses for DC's.

I am. That's why it's wierd...