Start Exchange services easily

If you want to start all the necessary Exchange services without starting unnecessary ones (like POP3 and IMAP4) you can use PowerShell from the Exchange Shell using this command:
Test-ServiceHealth | Select-Object -Expand ServicesNotRunning | Start-Service
Quick, easy, and intelligent.

Set the mail attribute from the UPN

If you use Office 365 with DirSync you’ll know that the email aliases and default reply address are set by the AD attributes mail and proxyAddresses.

If you only need the one alias, and for that alias to be the default reply address, it is sufficient to populate the mail attribute in Active Directory.

I prefer to have the mail and UPN have the same value. To copy the UPN value to the mail attribute for all users without a mail value, open a PowerShell window as an admin on a DC, and import the Active Directory module.

Import-Module ActiveDirectory

Then run the following command, changing the OU as required to suit your purposes.

Get-ADUser -SearchBase "CN=Users,DC=Contoso,DC=com" -filter * -Properties * | Where { $_.emailaddress -eq $null } | % { Set-ADUser -emailaddress $_.userprincipalname }

Server 2012 R2 GUI disappeared? How to re-enable it

I had to remove the .NET 4 feature from a Server 2012 R2 machine to repair the installation after a failed SQL Server 2012 install. When I rebooted, no GUI!

To enable it again, use the command below from an administrative command prompt.

dism /online /enable-feature /all /featurename:Server-Gui-Mgmt /featurename:Server-Gui-Shell /featurename:ServerCore-FullServer

Manually triggering Windows Azure Active Directory Sync

If you’ve set this up to synchronise your users with Office 365 (or any other service which uses Azure AD on the back end) then you’ll have probably read the documentation I did which suggests re-running the setup wizard if you need to synchronise accounts outside the regular every-three-hours default schedule.

Thankfully there is an easier and faster way to do this.

Open PowerShell, and navigate to the install directory for the sync tool. This is probably C:\Program Files\Windows Azure Active Directory Sync. Run .\DirSyncConfigShell.psc1 and a new PowerShell window will open. In that windows run the Start-OnlineCoexistenceSync cmdlet, and your sync will begin.

Thecus NAS devices – when things go weird

I’ve use a few Thecus NAS devices, but most of my experience has been with the N8800Pro and the N5200XXX. Both have, at various times, given me a great deal of grief.

The first thing to note is that these devices are only doing software RAID. This is a pain, because of the performance implications. This is also a boon, because of the recovery options it gives you. Either way, it’s good to know before you buy.

The second thing to note is that a power failure can, on occasion, cause disks in the array to be incorrectly flagged as failed. If you are very unlucky, this may cause your array to not only become degraded, but also just to fail to mount. If you can pull the disks out and identify them, you can force the disk improperly flagged to be marked clean and remount your array. Slot the disks back in to the Thecus (you labelled them, right?) and everything should start normally.

The third thing to note (and the inspiration for writing this post) is that sometimes, when you change the network configuration, the Thecus will start to lie to you. It will claim that it is restarting, but isn’t. Or that it is shutting down, but isn’t. Or that it is changing the network configuration, but, you guessed it, IT ISN’T. Pings are maintained the whole way through these procedures, as is access to the admin web interface.

This is bollocks.

The only way I’ve found to get around this rubbish cleanly is to install the HiSSH module from Thecus. When you have downloaded and installed, make sure you activate it. Use Putty to connect to the IP of the Thecus, and use the username ‘root’ and your usual admin password. The just use the bash command ‘reboot’ and you’re away.

If you own a Thecus NAS and it’s compatible with that module, download, install and activate it now. If things seem screwy, you’ll have another hammer to bash away at the problem with.

Getting KMS hosting working on Server 2012 Core

I had occasion to set up a Windows Server Datacentre 2012 Core VM recently, as a domain controller, FSMO role holder, and DNS server.

Since the network didn’t have a KMS host in use (but did have KMS keys) I thought I’d set it up as one.

Installing the key and activating the host is a cinch. From an administrative command prompt:

slmgr -ipk <key>
 slmgr -ato

But to get other clients to connect to this host, there are a few hoops to jump through.

First, you need to set a firewall exemption for the KMS traffic. From the same command prompt:

netsh advfirewall firewall set rule group="Key Management Service" new enable=yes

You’ll also need the DNS entry for the KMS service. This should be created automatically by your first KMS host, but if it isn’t there are a few permissions you’ll need to set. I followed the broad instructions here to allow for adding another KMS host in the future. In my situation, however, the KMS entry was automatically created.

It’s also worth noting that if you have multiple DNS servers (you do, don’t you?) then you’ll want to wait for, or force, replication of this record between those servers to avoid red herring chases of spurious DNS errors.

Your last obstacle should then be actually getting enough clients to try to authenticate that your KMS host can activate them. If you have a bunch of servers, this is easy again. Five servers should tip you over to activation, or you can settle for 25 workstation clients.

If you need the KMS client keys, everything from 2012 R2/8.1 on down is here:

Server 2012 VM Replication with Workgroup hosts

Replication between two 2012 Hyper-V hosts that aren’t members of a domain is a little more complicated than the domain-joined route. Between two resources, you should be able to get this set up with a minimum of fuss, however.

An excellent, step by step guide:

The only shortcoming here is that if you plan to do this replication as a kind of internal-only disaster recovery option, buying SSL certificates might not be worth it (although the certs you would need are pretty cheap). This is particularly true if you’re just testing and don’t want to spend money on certificates you’ll be throwing away.

Implementing self-signed certs is pretty easy as well. There’s a decent, though flawed, guide from Microsoft here:

The flaws are a couple of typos, and a registry key not included that your environment may require. Check the comments for the extra information you’ll need.

Note that you need the makecert.exe tool from the Windows SDK. If you don’t have this (or Visual Studio) it’s a quick and easy install.

I came across one infuriating gotcha, in that I ran the makecert.exe tool from a PowerShell window, and on the longer commands received errors about too many parameters. Hunting around for solutions led me up the garden path chasing improperly coded dashes. The solution is much easier: run this from an elevated command prompt, not from PowerShell. Worked for me straight up.