Problem using Active Directory Web Services?
Problem using Active Directory Web Services?
So, a friend of mine emailed me that he was having a problem running the active directory cmdlets. Here is what he received:
It’s an interesting problem, one that I had seen in the past in a few of my own virtual environments, but not a problem common in the real world. In fact, a quick Google/Bing check gave no results for the actual problem. So, I thought I would mention it here, even though it is a rare issue. Here’s how I originally diagnosed this problem.
Notice the first error, well not an error really – after all it is in yellow and says “WARNING:” in big letters, notice that an error occurred initializing the default drive. Now those of you that work with AD and the cmdlets know that when you import the module, a provider loads a drive to access AD named “AD:”. This message is telling us it couldn’t create that file system, but notice WHY. The rest of the message reports that it was ‘Unable to find a default server with Active Directory Web Services running.’ Well, that’s the kind of error message I like, tell me what happened and tell me why.
Notice I also attempted to run an AD cmdlet, just to display another version of the error message. It’s the same error just all red and nasty looking. So, it would appear that on my domain controller, the ADWS is stopped. This should be easy to fix.
I checked the state of the service running:
PS> Get-WmiObject –class Win32_Service –filter
‘name=”adws”’
First of all, I like using the WMI class rather than Get-Service because it reports the StartMode of the service. I can quickly tell from this that the service is running and the StartMode is Automatic (AUTO).
Seems to be running, so let’s check the error log:
PS> Get-EventLog –Logname ‘Active Directory Web Services’
–EntryType Error –Newest 5 | Select-Object –Property
EventID, Message | Format-Table –AutoSize -wrap
So, there are 1202 errors. I don’t know what that means of course, but the message is telling me that ADWS is having issues. At this point, most people will start to Google/Bing the error, and I did that too. The problem is that you quickly discover that this is a rabbit hole. The few results that I got from Bingle/Boog were obviously not my problem; they were strange registry hacks to fix issues that had nothing to do with ADWS. That’s when my spidey senses kicked in. This is not a real problem, it’s a mistake.
Sometimes, very rarely, a service will need to be restarted, let’s try that and then remove and import the module again:
PS> Restart-Service –name ADWS
PS> Remove-Module Act*
PS> Import-Module Act*
No error. Everything worked. Wait, this is not right. It’s true that my current problem is solved, but I know that this should not have happened in the first place. As much as we like to poke fun at “Windows” and use the phrase “Just reboot it”, I know that this is almost never the case. Windows Server is VERY WELL written and tested. Something else must be causing this issue.
I restarted the domain controller:
PS> Restart-Computer
After the restart, I again imported the AD module. Guesses? It failed again. I restarted the service and it worked fine, restarted the DC and it failed. I now have found the true root of the problem. Now I can fix it and never have it happen again.
Remember how I checked the ADWS service and it reported running and a StartMode of AUTO? Here’s the problem: The ADWS service needs to wait until the AD service is completely started or it won’t properly connect and cause this failure. I know the 1202 message says that ADWS will attempt to reconnect, but it never does.
To solve the problem, ADWS needs to start after the AD service has started. How can you do this? Easy, there is a new option for the StartMode of a service called “Automatic (Delayed Start)”.
Now here is the part that sucks. PowerShell cmdlets and WMI can’t deal with this StartMode. So, let me show you graphically.
On my DC, the StartMode was set to “Automatic”
I need to change this to a delayed start so that it appears like this:
There are a couple of ways to do this, none of them PowerShell because WMI and
Set-Service don’t understand the new StartMode type. You can use PowerShell to change this in the registry, but why work that hard. Just change it in the GUI. But if you’re hardcore and really need a command line to do this, you can use this:
PS>cmd.exe
C:\>sc config ADWS start= delayed-auto
(note the space after the equal sign. That is important.)
And there ya go, a permanent solution to a rare problem, one that you might run into as well.
Knowledge is PowerShell,
Jason Helmick
Director of PowerShell Technologies
Interface Technical Training
You May Also Like
Active Directory Web Services, AD cmdlet, ADWS, Powershell, StartMode, WMI
A Simple Introduction to Cisco CML2
0 3804 0Mark Jacob, Cisco Instructor, presents an introduction to Cisco Modeling Labs 2.0 or CML2.0, an upgrade to Cisco’s VIRL Personal Edition. Mark demonstrates Terminal Emulator access to console, as well as console access from within the CML2.0 product. Hello, I’m Mark Jacob, a Cisco Instructor and Network Instructor at Interface Technical Training. I’ve been using … Continue reading A Simple Introduction to Cisco CML2
How to use AWS CloudFormation templates to automate solutions inside Amazon AWS
0 380 0In the AWS Class here at Interface, we actually build fully automated solutions with AWS CloudFormations. Here’s an overview of using AWS templates using CloudFormation. CloudFormation is basically an “infrastructure-as-code tool” where you can go into a declarative document and define all the resources that you want and feed the document into the CloudFormation … Continue reading How to use AWS CloudFormation templates to automate solutions inside Amazon AWS
OSPF Adjacency Troubleshooting Solution – Getting Close to the OSPF adj
0 249 1In this video, Cisco CCNA & CCNP instructor Mark Jacob shows how to troubleshoot OSPF Adjacency issues by showing the distance between routers with the show ip ospf neighbor command.
See what people are saying...