Monthly Archives: October 2012

OK so I decided to take a look at Windows Server 2012 and obviously the first thing you want to do after installation is to add AD DS. This is a pretty straightforward operation, not a whole lot different to how it’s done in Windows 2008. Simply select roles and features, add AD DS and follow the wizard through, creating the new forest, domain and DNS on the way.

However this is where I started to see some problems. I can’t say for sure whether I am the only one to experience this problem but as soon as the installation finished I was unable to open any AD tools and I was presented with an error similar to the following:

“The Specified Domain Does Not Exist or Could not be Contacted”.

My initial reaction after some minor troubleshooting was simply to remove and re-install it, after all this was a brand new installation and I really shouldn’t be seeing these issues on such a virgin server. I removed and reinstalled twice but still saw the same issue. Now as much as I love a challenge, I’ve been a busy man recently with one thing and another and finally this was an opportunity to use one of my support calls up that came with my Technet subscription. Last year I didn’t use any and it annoyed me I couldn’t carry them over. But I digress. I will therefore blog their analysis which finally fixed the issue. Apologies for the slightly iffy grammar, I’ve tried to fix the worst of it! I am still at a loss why I have experienced this issue, I’d be interested to hear if anyone else has had similar issues with server 2012.

___________________

=> On server 2012 made sure we have default shares “Sysvol & Netlogon” available as shared. This wasn’t the case.

=> With server 2012(a New Forest & Domain) the Sysvol replication is done by DFSR, thus checked the events in DFSR for any errors/warnings. We found the following :-

“The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled”

=> We ran the following Command in order to recover from the Issue, and resume the replication :-

With Server 2012 being the first DC in domain, the Sysvol replication is done using DFSR and detailed analysis of the DFSR logs yesterday revealed the DFSR service itself was in a state of error. We were getting an event id 2213 wherein the DFSR Jet database was not shutdown properly. This happens every time the service is stopped. Moreover by default auto recovery is not enabled for DFSR and without this starting and running correctly, he Sysvol & Netlogon shares weren’t getting shared. When we found the event we first fixed the DFSR database for Sysvol as per the KB and then resumed the replication using WMI command. This made sure the database is set correctly and the replication is underway. Sysvol and Netlogon were then shared.

MICROSOFT SUMMATION

PROBLEM DESCRIPTION:-

Unable to Open AD Snap-Ins and Getting The Specified Domain Does Not Exist or Could not be Contacted

RESOLUTION:-

=> We promoted a server to a domain controller running 2012, the dcpromo process went fine without any issues, however when the server was restarted we couldn’t open any of the AD Snap-Ins and not DNS

=> The DNS zones failed to load and the snap-ins error out with “The Specified Domain Does not exist or could not be contacted“

=> When checked the serer we found the Default Shares of “Sysvol & Netlogon” missing

=> The server is running 2012 so the Sysvol replication would be on DFSR, thus we need to make the server authoritative for the same

=> We first made sure we have policies and scripts created fine, once done we followed the steps in KB 2218556 (The steps were followed in LDP as ADSIEDIT would not load the partitions)

=> Once we were able to perform the steps we checked the events, were getting the event for DFSR Database issues, also checked the Debug Logs in Detail, and ran the following :-

I was recently asked to come up with a solution to update our entire print server esate (around 600 boxes) with univeral PCL6 and PS drivers over x86 and x64 architectures. Specifically in this case I was asked to update with Lexmark and HP drivers although I see no reason this solution shouldn’t extend to any other manufacturers.

Since we have SCCM, my immediate idea was to create a package and push all packages out to the servers concerned but I found some shortcomings when creating the driver packages. Lexmark provide a tool to create the packages but I found I was unable to install both x86 and x64 drivers on the same machine. In fact, the executable created for the x86 drivers just threw errors. For the HP drivers, I had to throw in a few command line switches but again it simply wouldn’t install both architectures of driver. I should point out that the print server I was using for the test was Windows 2008 x64.

So another method was required. After much testing, I found the most reliable method was to use the Microsoft utility, prndrvr.vbs. This utility (along with several others) can be found under C:\Windows\System32\Printing_Admin_Scripts\en-US on the print server. I then deployed these using a task sequence in SCCM, running this utility with the drivers in question. Everything installs just fine and I don’t get any of the other rubbish which the manufacturer utilities include, such as extra printer objects, pre-configured ports etc. I have outlined what I did below for the HP drivers but remember, this should work for any print drivers.

Download HP Universal Drivers package from the net. Create a folder called HPUniversalDrivers in C:\Temp on your test workstation. Create another folder inside called HPUPD. Copy xcopy.exe into this folder. Copy the 32bit and the 64bit folders out of the HP Universal Drivers package into C:\Temp\HPUniversalDrivers\HPUPD. Finally copy prndrvr.vbs into C:\Temp\HPUniversalDrivers\HPUPD. Your HPUPD folder should now contain two folders (32bit and 64bit) and the vbs script.

Create a package in SCCM pointing the source to the location we have just described on your test box, eg \\testbox\C$\temp\HPUniversalDrivers, create a distribution point and update it. You don’t need a program.

Decide which driver version you require. You may have to dig about in the .inf files to find the one for your particular requirements but for the purposes of this blog I required v5.4 which could be found in hpcu118d.inf:

Your task sequence is now complete. Next, create a collection and add the print server of your choice to the collection. Advertise the task sequence to the collection and you should be good to go. This example will install both x86 and x64 drivers, PS and PCL6.

Disclaimer: I am in no way responsible if you accidentally deploy something nasty to your whole estate. Please test responsibly before deployment!