Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Fixing “The DNS server was unable to open Active Directory” errors

Posted: July 25th, 2015 | Tags: , , , , | Category: Windows | §

For no apparent reason my home testlab went wonky today! Not entirely surprising. The DCs in there are not always on/ connected; and I keep hibernating the entire lab as it runs off my laptop so there’s bound to be errors lurking behind the scenes.

Anyways, after a reboot my main DC was acting weird. For one it took a long time to start up – indicating DNS issues, but that shouldn’t be the case as I had another DC/ DNS server running – and after boot up DNS refused to work. Gave the above error message. The Event Logs were filled with two errors:

  • Event ID 4000: The DNS server was unable to open Active Directory.  This DNS server is configured to obtain and use information from the directory for this zone and is unable to load the zone without it. Check that the Active Directory is functioning properly and reload the zone. The event data is the error code.
  • Event id 4007: The DNS server was unable to open zone <zone> in the Active Directory from the application directory partition <partition name>. This DNS server is configured to obtain and use information from the directory for this zone and is unable to load the zone without it. Check that the Active Directory is functioning properly and reload the zone. The event data is the error code.

A quick Google search brought up this Microsoft KB. Looks like the DC has either lost its secure channel with the PDC, or it holds all the FSMO roles and is pointing to itself as a DNS server. Either of these could be the culprit in my case as this DC indeed had all the FSMO roles (and hence was also the PDC), and so maybe it lost trust with itself? Pretty bad state to be in, having no trust in oneself … ;-)

The KB article is worth reading for possible resolutions. In my case since I suspected DNS issues in the first place, and the slow loading usually indicates the server is looking to itself for DNS, I checked that out and sure enough it was pointing to itself as the first nameserver. So I changed the order, gave the DC a reboot, and all was well!

In case the DC had lost trust with itself the solution (according to the KB article) was to reset the DC password. Not sure how that would reset trust, but apparently it does. This involves using the netdom command which is installed on Server 2008 and up (as well as on Windows 8 or if RSAT is installed and can be downloaded for 2003 from the Support Tools package). The command has to be run on the computer whose password you want to reset (so you must login with an account whose initials are cached, or use a local account). Then run the command thus:

Of course the computer must have access to the PDC. And if you are running it on a DC the KDC service must be stopped first.

I have used netdom in the past to reset my testlab computer passwords. Since a lot of the machines are usually offline for many days, and after a while AD changes the computer account password but the machine still has the old password, when I later boot up the machine it usually gives are error like this: “The trust relationship between this workstation and the primary domain failed.”

A common suggestion for such messages is to dis-join the machine from the domain and re-join it, effectively getting it a new password. That’s a PITA though – I just use netdom and reset the password as above. :)

 

Print Management console to manage printers

Posted: May 28th, 2013 | Tags: , , , | Category: Windows | §

Discovered the Print Management console today. Wonder how I missed it so far! It’s such a useful tool when you have many print servers and would like to manage them all. Moreover, if your print server is a Server Core install, then using the console definitely beats typing the commands and scripts that are provided by default to manage the print server on Server Core.

Couple of things as a note to myself:

  1. A 64-bit server requires 64-bit drivers to be installed. This was surprising to me. Always thought 32-bit drivers were ok even if the OS is 64-bit. But no, that won’t do for printers. You have to install the 64-bit drivers, but you can install additional drivers – that are 32-bit – for clients and such. So in a way, yes, a 64-bit server can have 32-bit drivers installed, but only as an additional set of drivers.
  2. When managing remote servers it’s better to add the drivers first using this console and then adding the printer. If you try adding drivers when adding printer, the dialog box showing progress tends to freeze and you might think everything’s stuck.
  3. It is better to add both the 64-bit and 32-bit (if you require) drivers to the server, and then add the printer. If you add the 64-bit driver first, then add printer, and then add the 32-bit drivers via the additional drivers dialog box, it gets added but trying to open the printer again gives errors that your client machine needs to have 32-bit drivers. (This is on a Windows 7 client managing a Server Core 2008 R2 machine so could just be a bug with my setup). So best to add all drivers first to the server, and then add printer.
  4. If you already added 32-bit and 64-bit drivers to the Print Management console, then when adding a new printer the 32-bit drivers are automatically picked up as additional drivers. No need to select them manually.
  5. Additional drivers can be added by opening the printer properties, going to the sharing tab, and selecting ‘Additional Drivers’. But like I said above, better to just add these additional drivers first itself by going to the ‘Drivers’ menu in the Print Management console.

Get-WindowsFeature missing

Posted: April 28th, 2013 | Tags: , , , , | Category: Windows | §

I always open up PowerShell on $randomcomputer and type Get-WindowsFeature expecting to get a list of Windows features. Sometimes it doesn’t work and then I Google on why that’s the case, forgetting that I’ve been down this route umpteen times. So here’s a post for myself.

The *-WindowsFeature cmdlets are available via the Server Manager module which in turn is either present by default (on servers) or installed via the Remote Server Admin Tools (on clients).

  1. Windows Server 2012: Modules are loaded automatically on demand so the *-WindowsFeature cmdlets are available without any additional steps.
  2. Windows Server 2008 R2: Import the Server Manager module and then the *-WindowsFeature cmdlets can be used.
  3. Windows 8: Install the Server Manager via RSAT. This makes the Server Manager module available for automatic loading and then the *-WindowsFeature cmdlets can be used. Windows 8 also provides (Get|Enable|Disable)-WindowsOptionalFeature cmdlets as part of the DISM module (which is present by default). These provide similar functionality to the *-WindowsFeature cmdlets (doesn’t work on remote computers though!). Add the -Online when using these cmdlets as they can work with the running instance or a mounted Windows image.
  4. Windows 7: Installing the Server Manager via RSAT doesn’t help. It doesn’t include the Server Manager module and so the *-WindowsFeature cmdlets are not available. An alternative is to install the 3rd party Client Manager module which gives the *-ClientFeature cmdlets.

Managing BitLocker disks on Server Core

Posted: April 25th, 2013 | Tags: , , , , , | Category: Windows | §

I have a Server Core 2012 that has two BitLocker encrypted disks on it. When I encrypted those disks the server had the full GUI but after I converted to Core there’s obviously no GUI to just double click and be prompted for a password etc. So need to use the command line tools.

There seems to be two ways.

First are the BitLocker command line tools. Manage-bde looks like the most useful command here. Using this one can see the status of all the drives on the machine, lock, unlock, set auto-lock auto-unlock, and also turn on or off BitLocker encryption on a drive.

Typing manage-bde in the command prompt gives you all the options. Each of these options have further switches which you can discover by typing manage-bde <option-name> -?.

To view the status of all drives on the machine:

To unlock an encrypted drive (with drive letter D:) to use with the system:

I use passwords, hence the -pw switch. If you use recovery keys or certificates there are switches for that too. manage-bde prompts for a password and unlocks the drive, mounting it on the specified drive letter.

To set the drive (with drive letter D:) as auto-unlocked:

That’s all. From now on the drive will be automatically unlocked when attached to the system.

The syntax for disabling auto-unlock and locking a drive are pretty obvious from the examples above. The thing to remember is you always specify the manage-bde command followed by a dash switch specifying what you want to do, and after that you specify the drive letter.

There are two other commands: Repair-Bde for repairing corrupted BitLocker encrypted drives and BdeHdCfg for setting up a drive with BitLocker encryption (though it doesn’t seem to be required any more as Manage-Bde includes some of this functionality).

Apart from the BitLocker command line tools you can also manage BitLocker via PowerShell. This is only for Windows 8/ Windows Server 2012 and is available via the BitLocker module (requires RSAT on Windows 8).

To view the available drives on a system and their BitLocker status do:

You can also check the status of a specific drive with the above cmdlet by passing it the drive letter with the -MountPath switch.

To unlock a BitLocker drive (with letter D:) do:

The cmdlet does not prompt for a password. You have to pass it via the -Password switch. You can’t pass the password as plain text either, so have to convert it to a secure string. Use the ConvertTo-SecureString cmdlet for that or just use Read-Host and convert the inputted text to secure string on the fly.

To set auto-unlock on a drive (with letter D:) do:

Similar cmdlets exist for locking and auto-locking drives.

After writing this post I discovered a TechNet article that goes into more detail on the above command line tools and cmdlets. Go check it out.

Windows Server 2008 R2 Core initial setup (part 2)

Posted: December 13th, 2012 | Tags: , , | Category: Windows | §

Once your Server Core network etc are configured it’s time to enable/ disable Windows features and roles.

To enable/ disable/ list Windows features and roles it’s probably easiest to import the ServerManager module into PowerShell and use the three cmdlets provided. But just in case you are not into PowerShell, or don’t want to install PowerShell and it’s dependency .NET (you are on Server Core and PowerShell & .NET aren’t installed by default there) there are two alternatives.

DISM

DISM is short for Deployment Image Servicing and Management. As the name suggests, it’s a tool for managing the disk image using which you deploy Windows. Starting with Windows Vista the installation files of Windows are stored in a (file based) disk image called the Windows Imaging Format (WIM). DISM is a tool that can manage this disk image before it’s deployed to a computer. But DISM is not just about managing disk images before they are deployed; it can be used also to manage a running instance of a deployed image. The latter is what we are interested here.

Disk images prior to deployment are known as offline images. Disk images that are currently running as the OS within which DISM is invoked are called online images. When you are dealing with an online image you also pass the switch /online to DISM.

DISM was introduced with Windows 7/ Windows Server 2008 R2 and has a pretty straight-forward syntax:

The switches of interest to use are /Enable-Feature, /Disable-Feature, and /Get-Features.

To get a list of available features:

To enable a feature:

As you can see, feature names are case sensitive (eugh!!), and DISM doesn’t automatically enable dependent features – we have to enable them ourselves (good in a way coz DISM won’t enable a whole bunch of dependencies without me realizing, but I wish there were a way to say go ahead and enable whatever’s required). In contrast, if you try enabling a feature using PowerShell with the ServerManager module, dependencies are automatically taken care of.

(Update: DISM in Windows Server 2012 and Windows 8 has a /all switch that automatically installs all the dependencies.)

The feature names are also not very intuitive – for instance to enable AD DS you need to enable the DirectoryServices-DomainController-ServerFoundation feature but that’s not very obvious coz of the ServerFoundation tacked at the end of the feature name, which makes you think it might be a scaled down version of AD DS. (Just as an aside: in the specific case of AD DS, even if you don’t enable the afore-mentioned feature yourself, dcpromo automatically enables it as part of its tasks). This TechNet article is helpful in understanding what the feature names are.

I also hate the fact the fact that there are so many switches to type, but hey, at least the names are logical and I am glad DISM doesn’t have any dependencies and works out of the box on Server Core too. PowerShell has much better switches, but you need DISM sort of to enable PowerShell and the ServerManage module features.

Apart from enabling and disabling features, it’s worth knowing that DISM can be used to upgrade between editions. Say if you are running Server Core Standard and want to move to Server Core Enterprise, DISM can do that.

Read more about DISM and upgrading images at this TechNet article and blog post.

Lastly, DISM can also be used to query the installed drivers:

Unfortunately while there is a /Add-Driver switch for adding drivers, it doesn’t work against an online image.

OCSetup

OCSetup is short for Optional Components Setup. This tool was introduced in Windows Vista/ Server 2008 specifically for Server Core. Windows Vista/ Server 2008 had the new modular architecture of roles and features, along with the Server Manager tool (GUI and command line) to manage these. However, Server Manager depends on .NET which is not enabled by default on Server Core, and so the OCSetup tool was provided for Server Core. This tool has a counterpart called OCList that gets a list of the optional components.

The names returned by OCList are same as the ones given by DISM.

Once you’ve identified the features you’d like, enable them using OCSetup:

Similar to DISM, OCSetup too is case sensitive and doesn’t automatically install dependent features. Moreover, it doesn’t give any output. To see whether the feature was enabled, you run OCList again and verify that it’s installed.

OCSetup has a much simpler syntax than DISM, but also doesn’t have the additional features that DISM has. Moreover, DISM is a useful tool to know for creating offline images for deploying on other machines, so it’s worth familiarizing oneself with DISM.

Windows Server 2008 R2 Core initial setup (part 1)

Posted: December 13th, 2012 | Tags: , | Category: Windows | §

Happened to set up a Server 2008 R2 Core machine today, so here’s a quick overview of the steps I followed.

Install drivers

If you need to install any drivers, browse to the folder containing the inf file and do pnputil –i -a pathtoinffile.

Configure the network

View the network interfaces and IP addresses:

Rename the interfaces:

An alternate way of viewing IP addresses and interfaces, using the netsh command as above:

View & set the DNS servers:

Disable an interface:

Disable IPv6 (thanks to):

Set computer name

Find the computer name (using either of these methods):

Rename (and reboot):

Activate Windows

Enter license key:

Activate:

I will talk about adding features later.