Group Policy Errors

This started with regular event errors Userenv 1030 and 1058, and MSExchangeSA errors 9143 and 9047.

Only 1 Windows 2003 Standard server, which runs Exchange 2003 for now, soon to migrated to a new server

There are no failures in NetDiag or DCDiag.

GPOTool, returns Error: DC List is empty on the server.

GPOTool from a workstation, works, but returns a version mismatch for 2 of 2 policies.

Group Policy Management errors with Network Path not found.  However GPM from a workstation works.

FQDN access \\<domain>\sysvol\<domain>\policies fails from the server, however, works from a workstation.

I'm at a loss, and ideas.

Thanks
Larry
EcoMediaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

kgreeneitCommented:
install the latest service packs and updates onto the server, reinstall the Group Policy Management console, verify permissions on the SYSVOL folder and check DNS for any duplicate entries for your server name.

Also, check the local hosts file for any old static entries.
0
oBdACommented:
Did that happen after a restart of the box?
Try it with a
dfsutil /purgemupcache
first, that might take care of it. dfsutil.exe is part of the W2k3 Support Tools.
Windows Server 2003 Service Pack 2 32-bit Support Tools
http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90

If that doesn't help, this article has some troubleshooting hints:
Userenv errors occur and events are logged after you apply Group Policy to computers that are running Windows Server 2003, Windows XP, or Windows 2000
http://support.microsoft.com/kb/887303
0
EcoMediaAuthor Commented:
kgreeneit,

The server has all of the latest service packs and updates.  GPM was freshiy installed.  DNS was checked.  The FQDN works from other workstations on the network that utilize the same DNS server.  Permissions on SYSVOL appear to be correct, again accessable by other workstations, just not the server.  Host file is clean.

lBdA,

Box restarted several times, all clean boots.  dfsutil  /purgemupchase didn't help.  Also ipconfig/flushdns , ipconfig/registerdns, stop netlogon, start netlogon did not help.

887303 was checked but didn't help.

Thanks
Larry
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

CynepMeHCommented:
Have you checked your userenv.log file yet? If not, here's some info:

http://support.microsoft.com/kb/221833
http://technet.microsoft.com/en-us/library/cc786775.aspx

This may shed more light as to what's happening.
0
CynepMeHCommented:
BTW, have you confirmed your DNS settings yet? Compare your DNS info between working and non-working system. Check to make sure your DNS is working properly and you're able to locate _SRV records.

http://support.microsoft.com/kb/816587

0
CynepMeHCommented:
Ah, sorry didn't see you already mentioned that you checked DNS. Well, still confirm you're able to pull SRV records.

Some other ???:
1. are you able to access any other share on the DC?
2. Please confirm - you only have 1 DC that's running exchange as well?
3. Is this system multi-homed (more than 1 NIC) if so, take a look at this one and see if it applies: http://support.microsoft.com/default.aspx?scid=kb;en-us;830513
0
EcoMediaAuthor Commented:
The DNS settings on both the workstations and server are the same.  Artical 816587 also checks out.

There are two errors in userenv.log

USERENV(18c.11cc) 19:50:33:759 ProcessGPO:  Found file system path of:  <\\EcoMediaSourceLLC.local\sysvol\EcoMediaSourceLLC.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(18c.11cc) 19:50:33:759 ProcessGPO:  Couldn't find the group policy template file <\\EcoMediaSourceLLC.local\sysvol\EcoMediaSourceLLC.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>, error = 0x35.

And

USERENV(18c.11cc) 20:09:28:132 ProcessGPOs: No WMI logging done in this policy cycle.
USERENV(18c.11cc) 20:09:28:132 ProcessGPOs: Processing failed with error 53.

Note:

\\ecomediasourcellc.local\sysvol\EcoMediaSourceLLC.local\Policies

Works on a workstation but not the server

\\ecomedia-dc\sysvol\EcoMediaSourceLLC.local\Policies

Works on both the server and workstation.  'ecomedia-dc' is the name of the server.
0
EcoMediaAuthor Commented:
1) Yes connecting to shares on the DC works, Browsing the network also works.
2) Yes one server which is the DC and yes it's running Exchange 2003
3) The server is not multi-homed.
0
ChiefITCommented:
Though you have one DC, look in event logs under FRS to see if you have events in the 13000's. You may have FRS metadata of a server that no longer exists. That could mess up your group policies.

As far as excahnge, it is most likely a DNS issue.

Though your not seeing issues on netdiag or DCdiag, intermittent network connectivity can be a result of SP1 on the server. Someone mentioned that updating to SP2 might help. I think this is the resolution to your problem.

Furthermore, it appears to be a communications problem and might be the software firewall of the server. So, you might check your software firewall, (like Windows Firewall).
0
EcoMediaAuthor Commented:
ChiefIT,

At this moment there is nothing in the FRS Event log, I don't recall ever seeing anything but informational events.

The SP2 is installed on the server.

Checked the firewall, even tried setting the servers ip dns record to loopback 127.0.0.1

Thanks
0
ChiefITCommented:
I am leaning towards something that may seem abstract:

Since this is a ONE server environment and you don't have a replication partner, (also there is no evidence of FRS metadata). I am beginning to believe you have a netbios communications problem for both mail and group policy:

Now, I know I am going to recieve a lot of debate on this because mail client software traditionally contacts the mail server via DNS. However, I am seeing some people use the Netbios name as the host mail server when configuring the Mail client to communicate with the server. So, in other words, if you set up your mail client to contact the server by:

Mail server host:
Mailservername (Netbios query)
Instead of:
Mailservername.domain.name (DNS query)
or insead of:
xxx.xxx.xxx.xxx (the IP of your mail server for a ARP query)

.... and you are having problems with netbios resolution, maybe the mail server is not contactable by the client mail software, (like thunderbird or outlook express).


Group policy is also replicated via using FRS and that uses DNS. However, Group policy is passed down using netbios broadcasts.

Since you are having problems with group policy and there is no Replication partner, as well as mail clients contacting the mail server. You may be running into a netbios problem.

To figure this out use a ping. However use it correctly.

First ping the server by Netbios name:
Ping mailservername (from the client)
Then ping by fully qualified domain name:
Ping Mailservername.domain.name
Then ping by IP address:
Ping xxx.xxx.xxx.xxx (the IP of your mail server)

Fixes:
We may need to find out why netbios isn't working

For Mail clients always use the fully qualified domain name as the name for the host mail server instead of just the netbios name of the mail server.
0
EcoMediaAuthor Commented:
ChiefIT,

I agree we have to look outside the box for this solution.  I am not a newbie to technology, been around for over 35 years.  However, you guys already have come up with a couple of things I hadn't tried, I appreciate the help.

All of your suggested pings worked from both a client and the server.

The server was running fine until about 4:45pm on the 20th, I picked up the problem via events around 10pm that day.  The only change Iogged for that day was the install of WebLog.  That was started about 10am and all the reporting scripts and web interface was up and running about 11am.  Although I have all the anti-software running it is always possible this is being caused by a virus, at this point who knows.

What I find curious is that upon entering, on a client, "\\ecomediasourcellc\" IE8 starts offering suggestions, basically all of the shares on the server.  On the server, starting entering \\eco... only gets your \\ecomedia-dc\sysvol, typing anything past \\ecomedia removes all suggestions.  Does anyone know the mechanism used to offer the suggestions, it maybe a lead.
0
ChiefITCommented:
Do you have file and print sharing enabled on the server?
0
EcoMediaAuthor Commented:
Both file and print sharing are enabled.
0
kgreeneitCommented:
Hi again, sorry about the delay on this one - I've been off the air for te last day or so, came across a similar problem on Windows 2000 a few years ago and was trying to remember what I did to resolve the issue, here's what I found when I tracked through my old customer call logs:

http://support.microsoft.com/kb/259151

http://support.microsoft.com/kb/271213

Try the fixes in each of these articles and let me know if it resolves the problem.
0
EcoMediaAuthor Commented:
Artical 259151 doesn't totally apply to Windows 2003, however, permissions on the pagefile were correct, and pagefile size is reasonable.

Artical 271213.  %SystemRoot%\SYSVOL\Domain\Policies appears to be intact and correct.  The directory and files are accessable.  GPUpdate works with our error on all workstations, but errors on the Server.

I checked the backups, although the entire %SystemRoot% directory and System State are included, the data contained in %SystemRoot%\SYSVOL\Domain\Policies is missing.  Another clue?

Is there a way to recreate the policy data from scratch?
0
ChiefITCommented:
What does IPconfig /all of the server say?

I was looking for node type, preferred WINS and DNS servers.

Also, I was looking to see if you were on a fixed IP and if that IP is a commonly used IP for some firewalls and Mass storage devices as their default IP, (like 192.168.1.1)
0
EcoMediaAuthor Commented:
Here is the output for ipconfig/all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : ecomedia-dc
   Primary Dns Suffix  . . . . . . . : EcoMediaSourceLLC.local
   Node Type . . . . . . . . . . . . : Broadcast
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : Yes
   DNS Suffix Search List. . . . . . : EcoMediaSourceLLC.local

Ethernet adapter Local:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek RTL8139/810x Family Fast Ethernet NIC
   Physical Address. . . . . . . . . : 00-1F-E2-4C-BA-4C
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.123.3
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.123.1
   DNS Servers . . . . . . . . . . . : 192.168.123.3

As explained earlier, the only change around the start of the failure was the install of a web activity software package.  There were no other known changes.

I think we are looking for some type of corruption or virus.  Virus scans have run clean.

Thanks
Larry
0
ChiefITCommented:
Node Type . . . . . . . . . . . . : Broadcast<<<<
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : Yes<<<<

I see conflicting info. You have your nic looking for a WINS proxy while your node type is strictly broadcasts.

Also:
DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.123.3
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.123.1
   DNS Servers . . . . . . . . . . . : 192.168.123.3
>>>> ?????????? Wins Server  <<<<

I see NO preferred WINS server.

Very important: Do you have a WINS server??? If so, do you have a WINS proxy??? If neither on both of these, do you have a remote site that netbios broadcasts must go through??

You have a few configurations to make in order for WINS and netbios to work right. Remember DFS shares, and therefor GPOs, are replicated between servers using DNS and then broadcasted out via netbios broadcasts.If you have a flat domain, you could elect to encorporate DFS over DNS and disable netbios all together.

Let me know how you wish to procede:

disable wins proxy?
change node type to mixed? (that would dictate if you are using broadcasts and WINS or just broadcasts)
encorporate DFS over DNS?


0
EcoMediaAuthor Commented:
I am open to try anything.

What are your recommendations.

Thanks
0
CynepMeHCommented:
Have you checked permissions on \\ecomedia-dc\sysvol?  I know this may not exactly be the situation but some hints are provided in this kb:

http://support.microsoft.com/kb/828760

"Each Group Policy object (GPO) is stored partly in the Sysvol folder on the domain controller and partly in the Active Directory directory service. GPMC, Group Policy Object Editor, and the old Group Policy user interface that is provided in the Active Directory snap-ins present and manage a GPO as a single unit. For example, when you set permissions on a GPO in GPMC, GPMC sets permissions on objects both in Active Directory and in the Sysvol folder. For each GPO, the permissions in Active Directory must be consistent with the permissions in the Sysvol folder. You must not change these separate objects outside GPMC and Group Policy Object Editor. If you do so, this may cause Group Policy processing on the client to fail, or certain users who generally have access may no longer be able to edit a GPO.

Additionally, file system objects and directory service objects do not have the same available permissions because they are different types of objects. When permissions mismatch, it may not be easy to make them consistent. To help you make sure that the security for the Active Directory and for the Sysvol components of a GPO is consistent, GPMC automatically checks the consistency of the permissions of any GPO when you click the GPO in GPMC. If GPMC detects a problem with a GPO, you receive one of the messages that is described in the "Symptoms" section, depending on whether or not you have permissions to modify security on that GPO"
0
CynepMeHCommented:
Ok, found it. Go through this article and if it doesn't help consider switching to Linux :-)

http://support.microsoft.com/kb/887303

0
CynepMeHCommented:
duh. sorry, didn't see you already went through 887303 - please disregard.
0
CynepMeHCommented:
the fact that your data seems to be missing from backups and the fact that you can't seem to "auto browse" \\dc_name\sysvol share are glaring indicators of permissions issue. This is definitely something you want to take a look at:

http://web2.minasi.com/forum/topic.asp?TOPIC_ID=16129

Also, confirm you have no "loopback" processing or explicit deny to policies. From a machine that has no problem "seeing" your GPOs, install GPMC and run through RSoP planning tool, filling in required parameters. You may find some further hints.
0
CynepMeHCommented:
Last spam for the evening, I promise :-) This is a last resort option...

http://support.microsoft.com/kb/315457

0
ChiefITCommented:
Oh wow, I lost track of this one. Sorry for the late reply.

I still don't know if you have a WINS server or WINS proxy.

This is how things work. Group policy is saved on that server you configure it on within the SYSVOL file folder. The FRS (file replication service), replicates the these policies, from one server to its replications partners. Then, netbios broadcasts distributes these files out. I see the node type is netbios broadcasts. However, you have a WINS proxy configured for this. If you don't have a WINS proxy, we need to change that setting and make sure we are not looking for a WINS server that doesn't exist.

Here is the problem with netbios and WINS. Netbios broadcasts are not routeable. That means they will not go through a VPN tunnel, across to a different subnet, to another VLAN, or across NAT. So, if you feel the need to route netbios broadcasts, you may have to enable a WINS connection between the two sites domain master browser. By election, that is typically the PDCe. Some use a WINS proxy to monitor all WINS data coming to and from that LAN.

Looking at the above IPconfig>>>What you are telling this computer is, I am going to a WINS proxy that doesn't even have a WINS server and we are not going to use WINS to communicate with the WINS server. Instead we are using netbios broadcasts.  See the problem????

0
EcoMediaAuthor Commented:
CynepMeH

I tried all of your suggestions and I still have the problem.

ChiefIT

I think I understand what you are saying.   This is out of my range of knowledge.  Researching the issue has not helped, maybe I don't know exactly what to search for.  If you can provide a step by step I will try to correct the issue.

I have to question why the server has been functioning without these errors for about 4 months then suddenly fail?

At this point I'm ready to bring a new server on line, then rebuild this one.
0
ChiefITCommented:
OK, this is not a problem. We will take it one step at a time:

1030 and 1058 give the location of the group policy object. Let's first make sure it exists within the sysvol file folder. You should see the GPT.INI within the file folder location if you follow the path.

Once done, make sure it exists on any other domain replication partners Sysvol file folder. The replication partners should be your other Domain controllers.

Also, how often are these events happening, (every 5 minutes or every 15 minutes)?

One thing you might consider is disabling windows firewall for about 20 mintues, and then seeing if these errors go away. Caution, only do this if you are behind a NAT router or enterprise firewall.
0
EcoMediaAuthor Commented:
The 1030 and 1058 errors are being logged every 5 minutes

The path exists, but cannot be accessed directly on the server.  The path is accessable from all other workstations.  

The path: \\EcomediaSourceLLC.local\sysvol\EcomediaSourceLLC.local\Policies\{31...\gpt.ini

From the server you can access:
\\Ecomedia-dc\sysvol\EcomediaSourceLLC.local\Policies\{31...\gpt.ini

There is only one server in the network.

Windows Firewall and ICS is disabled, we are located behind a Firewall appliance.

0
ChiefITCommented:
In that case, you have a DNS problem.

This means that your servers are unable to replicate the sysvol and netloogon shares between them. Check your Event viewer logs and look in the FRS event logs for errors in the 13000's. If so, you have to reset your replication set. Let me know if these events exist.

Event 13565
Event 13508
Event 13566

Or any other event in event logs.

When recieving 1030 and 1058 every 5 minutes it means the servers are unable to communicate and replicate your sysvol and netlogon shares. You may have a partial repliation set between the servers. A partial replication set is known as JOURNAL WRAP> This is easily fixed but we will have to fix the DNS discrepancies first before fixing Journal Wrap.

Don't let this information get to you. All we want to know now is what errors are in your FRS event logs.
0
EcoMediaAuthor Commented:
Sorry for the delay, I was out of town on business.

The only entries in the FRS events are:

13501 - FRS Started
13516 - FRS no longer preventing the computer..... from being a DC

Just a reminder, there is only one Server in this domain.

Thanks
LArry


0
ChiefITCommented:

13501 - FRS Started
13516 - FRS no longer preventing the computer..... from being a DC

Not to be a pessimist. But, this tells me that FRS was down for a period of time. So, we should figure out why. DNS connections can be intermittent. Do you notice any slowness on the DC when contacting outside websites, maybe even timing out periodically?
0
EcoMediaAuthor Commented:
Not down for a period of time just a server reboot.  These are the messages I get when a server reboot is necessary.

The only thing I have noticed is that IE8 from workstations cannot make the initial internet connection occasionally,  But Chrome doesn't seem to have a problem.

To be honest I do not have a lot of experience setting up a DNS server.  I would not be surprised it this was the problem.  My only doubt is that workstations have no problem accessing sysvol.

Regards
Larry
0
ChiefITCommented:
Larry:

How do things look?
0
EcoMediaAuthor Commented:
I decided to rebuild the server on Sunday.  All looks good as of now.

Larry
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.