User Profile Service error

Recently I was domain joining a number of machines which had previously been a member of another domain. Some of the Windows 10 machines had been upgraded from Windows 7, and this left an issue in the Default profile which cause an error when creating a new profile.

This error occured when trying to log in with a domain user.

The solution is simple:

  1. Find a healthy Windows 10 machine, preferably one that has been originally installed with Windows 10
  2. Copy the folder “C:\users\Default” onto a USB-stick (or a file share)
  3. Log on the affected machine with a local admin account
  4. Backup (or rename) the exisiting Default folder (hint: it’s hidden)
  5. Copy the Default folder from your USB stick into “C:\users\” on the affected machine
  6. Try to log on with the domain user

I read a lot of suggested solutions to this issue, many requiring complex forensics into registry, and file analysis on the default and affected profiles. This is the only solution I was able to come up with which in my case had a 100% chance of success.

Restoring an Active Directory backup to an Azure VM

When backing up Active Directory in your local data center, you usually have control of everything from power and cooling, through networking, to physical machines and hypervisors. This also gives you control of the terminal for your virtual machines. In the Azure cloud however, when installing an IaaS VM, this VM is unavailable during reboot. No console, no terminal, no nothing; until the VM starts responding to services defined by the ports you’ve opened through your endpoints, you’re in limbo.

This isn’t usually a problem, but when doing an Active Directory restore, authoritative or otherwise, console access us often used to force the computer into Directory Services restore mode.

Let me take you through an AD restore in Azure. First of all, here’s my status quo:

I’ve got an OU named BackuptestOU, which I’m deleting

Now for the restore:

  • Open System Configuration (Windows key, type System Configuration)

  • Here’s how it differs from a typical AD restore. Go to the tab Boot and make the following selections

  • Press OK and select Restart
  • Log on with your Domain Services Restore Mode username and password
  • Before starting the Restore, revert boot options. Open system configuration again, and set the options as below to avoid rebooting into Directory Services restore mode after the restore.

  • Open Windows Server Backup and press “Recover”

  • Choose the correct location for your backup (in my case local)

  • Select the point in time you’d like to restore to

  • Select “System State”

  • Select “Original Location” and tick of the checkbox “Perform an Authoritative Restore of Active Directory files

  • Read this warning and confirm this warning by pressing ok

  • Press Recover. I like to have the server reboot automatically, but if you’d like to retain control of the reboot, leave it unticked

  • Select Yes to confirm starting the recovery

  • Wait for the recovery process to complete

  • And last, I demonstrate the AD restore is successful by showing you the OU I deleted. My backup was taken before I moved the last user, which is why there is only one user present.

So I hope this gives you some input on how to manage Active Directory in the Azure cloud. Please feel free to comment any question below.

RSAT for Windows 10 Technical Preview

Those who have tried have failed. Installing Remote Server Admin Tools (RSAT) for Windows 8 on Windows 10 Technical Preview won’t work. However, Microsoft has now released RSAT for Windows 10 and you can get it here

Copy group memberships for AD users

This techtip handles how to copy group memberships from a single user to one or more users in your organization. In order to accomplish this we use only the Active Directory module included in RSAT or available with Windows Server 2012.

In order to copy the group membership to several users, simply add a foreach-loop in the script.

In the last example, the variable $users would typically be populated using the the cmdlet Get-ADUser to pull from AD based on specific criteria, like OU etc.

This script only adds groups, it does not replace existing group memberships.

















Automating best pratice for security groups in Active Directory

In order to maintain best practices in a multi domain forest, we occasionally have to create file and application access groups to secure sensitive resources we manage. Creating a 3 groups to do this is a lot of hassle, but it needs to be done, however you don’t need to do it manually.

I created a script to take care of this day to day task for me. The script basically does 3 thing:

  1. It checks if a security group with that name already exists and if so it aborts.
  2. It creates 3 security groups: a “Domain Local” group for rights assignment, a “Global” group to put my users in, and a “Universal” group to link the Global and Domain Local groups, as well as to link groups from other domains in our forest.
  3. It asks the user what folder to add rights to and what rights to add (Read, Write and/or Modify) and then sets those rights on the appropriate folder.

The script uses Quest Active Roles AD Management snapin for Powershell (available here)

I’ve added logging using the transcript functionality, and if you check out line 19 and 114 you see that I’m starting and stopping logging to a specific file using the “Start-Transcript” and “Stop-Transcript” cmdlets. This means that the script will throw and error in ISE since it doesn’t support transcripting, but running it in a normal powershell windows will ensure that everything happing between line 15 to 113 get’s logged!

Without further ado, heres the script:


I still consider myself a novice at Powershell, however and advanced one at that, and I’d love to get feedback on better approaches to my scripting, both in the sense of optimizing the script for performance, and simplifying the script itself. I’d also be happy to answer any questions regarding the script 🙂

Updating KMS server settings

I encountered a weird problem with our Key Management Server (KMS) and client licensing recently. The client I’m working with has 3 domains whereas there is a full two way trust between two of them, and limited trust towards the third.

For some reason our Vista client (yes, Vista) we’re trying to update the license towards a KMS service on a domain controller in the third domain with limited trust. It also seems KMS has been deactivated on this server, but that wasn’t the challenge.

To update the KMS server address you need to run the Visual Basic (VB) script c:windowssystem32slmgr.vbs. You can add argument to view the current configuration (-dli), manually set the KMS server (-skms) or do an autodiscover of the KMS server address (-ato).

In this case I ran the following command to see the current config:

I saw that the KMS server was not the one I expected for clients in this domain, so I ran this command to do an auto discover:

This generated an error:
Error code and message: 0xC004F039 The computer could not be activated. The Key Management Service could not be reached.

The cause for this error in our case was that the Vista client tried to update the license towards the last server it updated against. There is no error handling routine in slmgr.vbs that tells the client to do an auto discover of possible KMS servers elsewhere if it fails towards the server it last updated against.

To resolve this I had to clear the name of the KMS server the client already knew in order to force it to discover the actual KMS server on the intranet. I ran the following command to clear the name and run the auto discover:


NB. If this had failed, there would have been one last solution. You can update the name of the KMS server manually, thus bypassing the entire auto discovery and eliminating that as an error source. This requires you to know the name and port (usually port 1688) of the KMS server, and is done with the “-skms” switch like this: