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:
- Find a healthy Windows 10 machine, preferably one that has been originally installed with Windows 10
- Copy the folder “C:\users\Default” onto a USB-stick (or a file share)
- Log on the affected machine with a local admin account
- Backup (or rename) the exisiting Default folder (hint: it’s hidden)
- Copy the Default folder from your USB stick into “C:\users\” on the affected machine
- 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.
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 “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.
This is going to be a short post, simply because it turned out to be ridiculously easy!
Traditionally when installing Active Directory Domain Services (ADDS) you’ve had to use DCPromo to initiate the install. Through this gui-based installation you could configure the name of your domain and your forest, your domain and forest level and whether or not to install a DNS-server along with your Domain Controller (DC).
You can easily do this using Powershell and it requires on two simple one line commands.
First you need to install the ADDS role on your server. Run this command:
Second, configure your ADDS role and decide whether or not to install DNS:
Install-ADDSForest -DomainName LAB.local -DomainMode Win2012 -DomainNetBiosName lab -ForestMode Win2012 –InstallDNS
Voila, you’ve just installed a new domain called LAB in a new forest.