DFS Replication and the SYSVOL Problems

I recently noticed on one of my domain controllers that there were some warnings in the Event Log for DFS Replication.  Well, actually what I noticed was that the SYSVOL folder on some of my DCs didn't have all of the GPO folders.  A bit of searching to find out what causes that led me to looking into the Distributed File Services Replications.  Which in turn led me to the event viewer.  Which led me to the Warning ID 2213 from DFSR.

The warning

Yay! I love warnings in the event viewer.  Wait, this is just a warning, "Hey, by the way I'm not replicating your crap any more and I'm not going to replicate it any more until you manually intervene."  Isn't that nice?  This looks like something that should be more than just a "warning."

The warning looks a bit scary, but it is very helpful in that it tells you exactly how to fix it.  Have to give Microsoft points for that one, put the fix right there in the warning.  I mean, you can copy and paste the command out of the warning message and into a command prompt and it'll fix itself.

Now, why exactly did I have to wade through the event viewer to find this warning and this command?  Where's Clippy when you need him?  A nice "Hey I noticed you didn't do a clean shutdown, would you like to re-enable your SYSVOL replication, it might be important?"  Why did they neglect that?  When I log back in it asks me why it was shut down improperly, why not take that same opportunity to ask about re-enabling the replication too?

But, I digress, back to fixing replication.  What you ask?  I'm not done yet?  I told you to cut and paste the command from the event description to fix it didn't I?

If you're like me, it didn't work.  I selected the text, I copied the text, I click on the Powershell prompt, waited it for it to open, I pasted the command and finally pressed enter.  Only to be greeted with an "Unexpected switch at this level" message.  Well that was nice and friendly.  I bet I need an elevated prompt.  So this time I right-clicked on the Powershell prompt and selected "Run as Administrator."  Surely that will fix it, nope, it doesn't, it gives you the same error message.  Ok, so I must have just not selected everything before I copied.  I tried it a few more times, nothing, same error message.

Now it's time to hit the internet.  I do some searching and I find this post over on howdoicomputer.com.  It looks like they ran into the same problem.  The trick is to use a regular command prompt, not a Powershell prompt.  How do you like that?  The answer's right in the event message, "from an elevated command prompt."  So Microsoft's be all end all Powershell prompt is useless when it comes to using this WMI command.

I also ran into the DFSR error 4012 that they mention in that same post over at howdoicomputer.com.

The error

By default, you've only got 60 days to correct the problem, after that it will not restart replication.  The quick fix for that is to change that default window to something greater than however many days you have been out of replication and then run the command again.  The command for increasing that default is:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=200

That 200 on the end is the number of days to increase it to (you can pick anything above how many days you're out)..  I'm a bit embarrassed to admit, that I had run substantially longer than the 60 day default (you can see in the screenshot) and had to increase it a lot to get it to run.  However, when I finished I did set it back its default of 60 days.

When it's all said and done you should get a Information event from ID 2214 that says the replication service successfully recovered.

It's fixed!

Assigning local rights through Group policy and making it work

Trouble getting local computer rights assigned through group policy?  Have you read all the articles that tell you to edit the GPO and assign the rights?  Are they still not showing up on your Windows XP machines?  That's the trouble I ran into.

Before I get too far into this.  Let's go back to begining.  We made the switch to from a Novell network (Netware servers, eDirectory, ZDM, iPrint and the Novell Client) to Microsoft network (Active Directory).  After the switch we needed someway to manage the rights that local users have on machines.  In the past we used ZENworks and when users logged into their computers (through the Novell Client), Zen would pick that up and create a local user for that person with the rights that we assigned and then seamlessly log the user into that account.  When using AD it doesn't work the same.  The users just log into the machine, because the machine is in the domain they don't get (or need) a local account.  Which is great, except that some of the people need to be administrators or power users.  I know I could go through group policy and assign specific rights, but we don't need that granular of control.  Just making them members of the local groups is good enough.

Now there's a couple of ways to get them in as member of a group.  The original way to do it with group policy was to use the Restricted Groups feature.  Doing it that way makes sure people are members of the group and that only those people are members of the group.  That's nice for some environments, but we don't need that level of control.  For us, all we need is to add people to groups from time to time.  There's a new way to do just that.  Well, I say new way, it's been around for 5 or 6 years.  Its through an addon to group policy called Client Side Extensions.  Microsoft bought out a company that was doing some neat group policies addons and then MS built it into Windows and released it free of charge for all to use.  But that's a story for a different day, the point is that I wanted to assign the group membership using this part of gorup policies. So I started doing my homework.  I read a lot of posts about using them and I dug through the MS documentation.  It seemed pretty straight forward, I made my own policy, I assigned it, then I tested it, and then I found out it didn't work.

What had I missed?  I went back through and double-checked everything.  And then I tested agian.... nothing.  And I tested again and again.  It just wasn't working for me.  As it so often happens I got pulled away to work on something else, but I had left the policies applied.  They weren't working but didn't appear to breaking anything, so what did it matter, right?  A few days passed and then I got back to working on this problem again and guess what, it worked.  Right... it worked.  Go figure.  What had changed?  I went back through everything and the only thing that had changed was my test machine.  Lesson learned, if at first you don't succeed, try a different test machine.

Now that I knew the problem was in my machine, I just had to figure out what exactly it was.  Back to the internet to see what pieces made these group policy extensions tick.  What I found was two different Windows update that make it happen.

The first one is KB915865 which covers XMLLite.  If you're running XP 32-bit here's that download link so you don't have to go looking for it http://www.microsoft.com/en-us/download/details.aspx?id=13978

The second update is KB943729 which covers the actual new Group Policy preferences.  If you're running XP 32-bit here's that download link as well, http://www.microsoft.com/en-us/download/details.aspx?id=3628

Now that you know what you need to you need to figure out what systems need it right?  Well the fastest way for me to tell if the computer is working right is to use NET LOCALGROUP ADMINISTRATORS at a command prompt.  We've got a couple of accounts that we add as local admins on all machines, if the only thing listed on that command is a "MyDomain\Domain Admins" then I know I'm missing one of the updates listed above.

How about a quick way to tell which update you're missing?  Check the C:\WINDOWS\SYSTEM32 folder.  The XMLLite update installs an XMLLITE.DLL file, if it's there, then the update has been installed (of course it could be corrupt or not registered correctly).  To see if Group Policy preferences update has been installed look for a GPPREFCL.DLL file.

So one command to see if it's working.
NET LOCALGROUP ADMINISTRATORS

And two commands to figure out what you're missing.
DIR C:\WINDOWS\SYSTEM32\XMLLITE.DLL
DIR C:\WINDOWS\SYSTEM32\GPPREFCL.DLL

After you install the updates just let the machine reboot and log back in.  I have noticed that on the faster machines if you log back in after the reboot with a machine that's supposed to be getting admin rights that it doesn't get the rights on first log in.  If you check the group memberships it shows up rights but you don't have admin rights.  I think what's happening is that the system is logging the account in before the group policies have time to finish applying and since the memberships haven't assigned when the account logs in it doesn't get the rights.  By time you can check the memberships it shows up correctly, but you don't have the rights because the weren't there at login.  The fix is to just log out and back in and then you'll have the rights.  The irony is that it seems like some of our slower machines are not affected by this, I guess the policy has time to finish applying before it actually starts processing the login.  Who knows?  If all it takes is a log off and back on, I'll take it.