Summary: Learn three ways to use Windows PowerShell to reset the computer secure channel.

 Hey, Scripting Guy! We have a problem with the computers in our computer classroom. We set up this classroom to teach new hires how to use our mission critical application. We are, however, not hiring as many people as we used to, and as a result it keeps getting longer and longer between classes. Now, we do not leave the computers turned on between classes, and often it takes an entire day to get the computers back on the domain when we decide to have another class. I researched the problem, and I have determined that the issue is with the computers being turned off for more than 30 days and the computers missing the secure channel password reset. Is there anything you can do to help?

—AP

Hello AP,

Microsoft Scripting Guy, Ed Wilson, is here. The great thing is that we released the Window Server “8” Beta, so I can finally talk about Windows Server “8” Beta just a little bit. I am sitting at my laptop sipping a cup of peach and hibiscus leaf tea (it is naturally sweet and caffeine free) and playing with Windows Server “8” Beta in a virtual machine. It is very cool—especially from a Windows PowerShell perspective.

AP, I have seen your problem many times. From firing up preconfigured servers, to starting up virtual machines that have been turned off for extended times, to desktop machines that are turned off for more than 30 days. In some countries (not the United States) where workers get several weeks of vacation, it is not uncommon for a worker to take four weeks off at a stretch. (This could also be the situation in a job share arrangement.) When the worker comes back, the computer does not talk to the domain.

There are a couple of ways to handle this. One way is to increase the amount of time between the changes of the secure channel password (but I do not recommend this). Another way is to remove the computer from the domain, reboot the computer, join the computer to the domain, and reboot again. On my laptop (where it takes nearly 10 minutes for the laptop to become usable after a reboot), we are talking about a 30 minute process.

There are other alternatives to this multiple reboot scenario. Each of these solutions could easily be placed into a Windows PowerShell script.

Use netdom to reset the secure channel

Netdom is a multipurpose tool that started life as a resource kit utility. It grew up, and was added to the operating system. The problem is that it is not a default part of the client operating system. In Windows Server 2008 and Windows Server 2008 R2, netdom is available when the Active Directory Domain Services role (AD DS) is added. In Windows 7, access to netdom becomes available when you install the Remote Server Administration Tools (RSAT). The syntax can be a bit tricky with the forward slashes and colons, but it can be done from within Windows PowerShell. Make sure the Windows PowerShell console runs with admin rights prior to executing the command. A sample of the syntax is shown here.

netdom reset /d:devgroup.contoso.com mywksta

The disadvantage to using netdom is that it is not likely to be available on client workstations unless the RSAT is installed.

Use Test-ComputerSecureChannel

The Active Directory module (see yesterday’s blog) contains a cmdlet named Test-ComputerSecureChannel. When used, it returns a Boolean value if the secure channel is working properly. This use is shown in the following image.

If the Test-ComputerSecureChannel cmdlet returns False, use the Repair switch to repair the secure channel. One way to automate this would be to create a scheduled task that executes on startup and runs the Windows PowerShell command that is shown here.

if(!(Test-ComputerSecureChannel)) {Test-ComputerSecureChannel -Repair}

Of course there is one major problem with this approach: You need access to the Active Directory module. On a client computer running Windows 7, this means installing the RSAT. On the server, it means adding the AD DS role. On Windows XP, it means you are out of luck. Of course, you can enter a remote Windows PowerShell session, load the Active Directory module, and use the cmdlet. But then of course, that is not checking the secure channel on the local machine, but rather the one on the server to which you just connected. There is no ComputerName parameter available for the cmdlet.

In the Windows Server “8” Beta, the Test-ComputerSecureChannel shows up by default. It is already installed and available. In Windows PowerShell 3.0 (which is in Windows Server “8” Beta), I do not even need to load any special module because the module that contains the cmdlet loads automatically on first use. The image that is shown here illustrates using the Test-ComputerSecureChannel in Window Server “8” Beta to test the secure channel.

Therefore, if you have access to the Test-ComputerSecureChannel cmdlet, it is certainly the easiest way to reset the secure channel.

Use Nltest

The Nltest command will work inside Windows PowerShell, and it is installed by default on Windows 7 and Windows Server 2008 R2. To gain access to nltest in Windows Vista or earlier versions of Windows it is necessary to install the admin tools.

Because nltest exists by default in Windows 7, Windows Server 2008 R2, and Windows Server “8” Beta, it is a good choice to use from an automation perspective. When you migrate everything to Windows Server “8” Beta (assuming that the Test-ComputerSecureChannel cmdlet exists in the RTM product), it will be the easiest to use. There are lots of switches and various ways of using nltest, but there is one command that will test the secure channel, and if it needs to be repaired, it will repair the channel. This command is shown here.

nltest /sc_verify:iammred

The image that follows illustrates using the command and the output that arises from the command.

AP, that is all there is to using Windows PowerShell to reset the secure channel on workstations. Join me tomorrow for more Windows PowerShell coolness.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy