Wednesday, June 17th, 2015
I am “crash and burn” testing windows 10. Painful but a good way to get the feel of it. One painful loss was the Active Directory module for Powershell. You have to have Remote Server Administration Tools (RSAT) and they stopped working for Win 10. There was a special release for the January version of Win10 but it died with the May version and Microsoft reported they will fix it with the general release.
What to do?
I thought about using one of my test VMs running Windows 2008. It had RSAT but when I tried to import the Active Directory module into Powershell; I received an error saying it did not exist.
I found there were a extra other steps needed to be done:
1) Import-Module ServerManager
2) Add-WindowsFeature RSAT-AD-Powershell
After that, I was able to import the active directory module.
There was a recent update to windows 10 and it nuked RSAT. Microsoft will basically fix it after the OS is released. *sighs*
Saturday, February 2nd, 2013
I have a script which uses psexec to check a few things on new servers. I ran the script and received the following message.
Couldn’t access *hosta*:
The handle is invalid.
Could not start PsExec service on *hosta*:
Access is denied.
Starting PsExec service on *hosta*…
Rather an odd message because another server with the same configuration didn’t have a problem. I checked a few things but did not find anything obvious. Server pings, remote desktop works, etc., etc…..
From the other box I tried to see if I could remote access the C drive via \\hosta\C$ and received this error:
Logon Failure: The target account name is incorrect
The AD account looked ok but when I checked the host; I found a typo. Instead of *hosta* there was *hosa* (obviously not the real name but you get the idea).
I deleted the domain account and simply renamed the server. The domain prompted for an admin level account to do this and rebooted.
Don’t forget to move the host to the proper AD group if you use them.
Moral of the story: DNS/AD is both a friend and enemy. DNS pointed to the correct server but simple things would not work while other things like remote desktop did. Well? Only because a previous problem prompted for a change in the negotiation level of RD.
It’s funny but I look back to my first AD design course and I remember the teacher repeating most AD problems are DNS related.
Sunday, September 16th, 2012
A user reported this error when he attempted to check the site name on a terminal server via the command: nltest /dsgetsite
A rather odd error as it usually appears on domain controllers and exchange servers. DNS was in order and there wasn’t an obvious error in the logs.
I checked which logon server was handling authentication for the terminal server via echo %LOGONSERVER% and found domain controllers in other countries were handling the authentication. I checked a couple other windows boxes and found the same errors.
This suggested the subnet for Active Directory was not configured or had a typo. I was not able to immediately verify this as AD is controlled by another group. I opened a trouble ticket and will wait for an answer.
I needed to solve the problem for the users who spotted this error. I found a registry entry would handle this issue.
From regedit; drill down the following:
Once you click Parameters, add a string word called “SiteName”
Add the current site name to the entry and exit regedit.
nltest /dsgetsite will now function as expected.
Not the best of solutions; but it at least it solved the user’s problem while the AD people figure out what is going on.
If I get an answer, I will update this post.
As suspected; a subnet range was missing from the AD configuration. It was added and the correct site and logonservers were appearing.