Before we dive into how to enable Active Directory Recycle Bin in Windows Server 2016, we will first explain what it is and when Microsoft introduced this feature. Active Directory Recycle Bin simply allows you to restore deleted objects from Active Directory. It can be a user account, computer account or a whole Organizational Unit (OU). Who did not accidentally delete an AD object in his career? Without this feature enabled, you had only a few choices. Either you could restore if you used a backup solution allowing you to restore individual AD objects (many virtualization backup vendors do that nowadays). Or you have had less chance and your AD server wasn’t configured to be backed up and you have to recreate the user and reinstall his profile on his computer.  

As a summary, LAPS is the Local Administration Password solution from Microsoft. This software changes the local administrator password on a selection of machines on a schedule and stores that password in plain text in Active Directory. The first time I came across LAPS was when I hear about project Honolulu and I’ll admit that I hadn’t heard about it before which is something of a shame because LAPS is one of those very handy little add-ins that Microsoft should be offering as part of the core AD experience. For those who haven’t come across LAPS before, LAPS is a handy tool for scenarios where you need to change or set the local admin password to something random because you need to give out that password.

When Availability Groups were introduced in SQL Server 2012, they were only available in Enterprise Edition. This made it challenging to move from Database Mirroring to Availability Groups, especially if you’re running Standard Edition.  To upgrade and migrate from Database Mirroring in Standard Edition, you either choose to upgrade to a more expensive Enterprise Edition license and implement Availability Groups or stick with Database Mirroring and hope that everything works despite being deprecated.

In this first blog post, I’ll walk you through to migrate Active Directory objects (users, groups, and workstations or member servers) between two domains in the same forest (Intraforest) using Active Directory Migration Tool (ADMT) 3.2. ADMT allows you to migrate objects (including users, groups, computers, profiles, service and managed service accounts) with the help of ADMT console, command line, and VBScript. However, in this post, I’ll focus only on ADMT console and command line.

Thanks to the previous part, we have SQL Server 2016 installed and configured. Before running the SCCM installation process, let’s remember the architecture we are implementing.

We’re not done yet. In part II we moved from the older CSP provider to a KSP provider but now we want to start issuing certs with a SHA256 hash. That’s what we’ll do here in part III. The final step is that we move from SHA1 to SHA256 and tell the CA to work with the KSP. This is a tedious job that involves creating registry files in order to change the existing registry keys we already backed up before.

Last year I have written a topic on Starwind to create VMs from PowerShell. That enables to automate the creation process without using a GUI, either from Virtual Machine Manager or Hyper-V Manager. But a VM deployment is not finished when the VM is created but when the application is deployed. Before deploying the application, the OS must also be installed and specialized. This topic shows you the method I use to deploy and specialize a VM without a single click.

On October 1st, Microsoft Exchange Team released the new Exchange Server 2016. Microsoft had been testing and improving millions of mailboxes in their Office365 environment before it released the product on-premises. In this article, I will describe a step-by-step guide for the installation of Microsoft Exchange Server 2016.

What works for 100 users very often doesn’t work for 10,000, and vice versa. Few vendors worry about making software created for the enterprise meet the needs of the SMB. Those who try to fit both worlds, rarely succeed. Specifically, let us look at Active Directory (AD) replication times. By default, AD is scheduled to do inter-site replication every 180 minutes (three hours), which makes sense if the AD is huge, and one or more of the sites is on the other end of connectivity from the past. This value can be changed from the default to occur as frequently as once every 15 minutes, representing a somewhat conservative minimum replication interval.