I had a client recently who has all 2008 DCs and wanted to introduce 2016 DCs. No big deal. Prep the domain and forest and off you go. Except that this client was running in 2003 forest mode. And that led to a different discovery: FRS was being used for SYSVOL/NETLOGON replication. And this is not going
to cut it in a modern AD. Migrating is not especially difficult but it requires a little know how, patience and perserverance.
This article by Patrick van den Born was a wonderful resource that had almost all that I needed to get the pieces in place.
*** Make sure to install DFS on all the 2008 DCs but do not create a namespace.
http://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distributed-file-system-replication/ – also good!
Test replication by going to the “scripts” folder in SYSVOL, adding a text file, and making sure that it IMMEDIATELY appears in all the other DCs’ Scripts folder.
The Client required Remote Desktop Sessions to be available to 17 contractors via a hosted server. They also wanted that server to be hosted within their existing Azure/365 portal.
The first thing was to connect their AD to the cloud. AD Connect had already been installed and had done the initial seeding of the accounts for Office 365. But it had not been enabled for password replication and so SSO was not in place. Further, the issue with users not synching properly was only because the user accounts were in the default USERS OU. AD Connect doesn’t like this. Accounts need to be elsewhere.
Domain Joined machines in the cloud
In order to join virtual servers and PCs in the cloud to the client.com domain and use domain creds for logins to these machines, we had to extend the AD to the cloud. There are a number of ways to do this and the easiest and simplest is to use Azure Active Directory Domain Services (AAD DS). This extends the domain to the cloud with no site to site VPN (which can be done within Azure) and no virtual server running in the cloud as a domain controller.
Domain Admins for AAD DS
In the AAD Dashboard, go to Groups and note the AAD DC Administrators
This is a global security group that only exists in the AAD DS world. It contains AD accounts that are allowed to be the equivalent of the Domain Admin role in Azure. You must be in the group to be able to do certain high level functions like joining Azure VMs to the Client.com domain.
AD Connect on the on premise domain controller
AD Connect controls the replication of all configured information from the on-prem DC to AAD DS. It is straightforward to use and will sync any OU’s data except for the default, built-in OU.
Azure Virtual Machines
Azure VMs are mainly managed in the classic portal and not the new one.
Here are the server information readings as configured by Microsoft on the server desktop
The server’s RDS configuration is set via Add Roles… as seen below
Configurable information for the Session Based RDS Deployment is listed here:
Most IT people know about the need to use SHA-2 Hash Algorithm when creating new CSRs for SSL certificates. But many of the Windows servers out there do not default to this hash and will generate a CSR based on SHA-1.
Here is a great articale onhow to generate the proper CSR using Windows Certificates MMC snapin.
How to create SHA2 CSR on windows server
I had a client recently who couldn’t run .bat files. It wasn’t one of those cases where the bat file would just open in notepad, it just wouldn’t do anything. And right-clicking gave no “run as admin” option either. The registry on this PC for .bat files was completely corrupted. You can’t fix this by associating the .bat extension with cmd.exe – that will just open a DOS (yeah, I’m old) prompt.
I didn’t find a whole lot on fixing this. But Since I knew that this info is in the registry, I knew that restoring the registry for .bat files should work. I found this great site that will allow you to restore all sorts of default file associations. Check it out!
I recently had to change 350 contact objects in a client’s Active Directory. Normally, I would have just used powershell for this sort of thing. But the technet article about the change to be made also mentioned a tool that I had heard of but never used: AD Modify.net. I decided to try it out.
It’s really a GUI of sorts that will allow you to make bulk changes to AD objects from an easy to use GUI. Just connect to the AD, choose your container and the objects within, and away you can go!
In this case, I had to remove the secondary SMTP address from hundreds of contacts.
Using the easy to navigate GUI, I added all the contact objects to be altered. I was then presented with an interface very similar to that of ADUC. I added the parameters that I needed and made the changes in no time flat.
If you need the functionality of PowerShell but are intimidated by the syntax, give this nifty utility a try!
We’ve all had it happen at some time or another. The BSOD!!!! Your PC crashes without warning, without remorse and without the chance to save the work you were doing.
What is happening during this time is that Windows is writing the information that pertains to the crash to a .dmp file. This file can provide you with valuable information as to the root cause of the crash. But, you have to have the right tool to analyze the file.
I recently had a client with this issue. So, I used my free copy of WhoCrashed to find the errant driver and correct it. This is a great tool! Check it out today!