Aug 132022
 
Azure AD

Many of you may be not aware of the Azure AD Connect 1.x End of Life on August 31st, 2022. What this means is that as of August 31st, 2022 (later this month), you’ll no longer be able to use Azure AD Connect 1.4 or Azure AD Connect 1.6 to sync your on-premise Active Directory to Azure AD.

It’s time to plan your upgrade and/or migration!

This is catching a lot of System Administrators by surprise. In quite a few environments, Azure AD connect was implemented on older servers that haven’t been touched (except for Windows Updates) in the years that they’ve been running, because Azure AD Connect “just works”.

Azure AD Connect End of Life

Azure AD Connect has to major releases that are being used right now, being 1.x and 2.x.

Windows Server 2022 Logo

Version 1.x which is the release going end of life is the first release, generally seen installed on older Windows Server 2012 R2 systems (or even earlier versions).

Version 2.x which is the version you *should* be running, does not support Windows Server 2012. Azure AD Connect 2.x can only be deployed on Windows Server 2016 or higher.

Click here for more information on the Azure AD Connect: Version release history.

Azure AD Connect Upgrade and Migration

For a lot of you, there is no easy in-place upgrade unless you have 1.x installed on Windows Server 2016 or higher. If you are running 1.x on Server 2016 or higher, you can simply do an in-place upgrade!

If you’re running Windows Server 2012 R2 or earlier, because 2.x requires Server 2016 or higher, you will need to migrate to another system running a newer version of Windows Server.

However, the process to migrate to a newer server is simpler and cleaner than most would suspect. I highly recommend reviewing all the Microsoft documentation (see below), but a simplified overview of the process is as follows:

  1. Deploy new Windows Server (version 2016 or higher)
  2. Export Configuration (JSON file) from old Azure AD Connect 1.x server
  3. Install the latest version of Azure AD Connect 2.x on new server, load configuration file and place in staging mode.
  4. Enable Staging mode on old server (this stops syncing of old server)
  5. Disable Staging mode on new server (this starts syncing of new server)
  6. Decommission old server (uninstall Azure AD Connect, unjoin from domain)

I highly recommend reviewing Microsoft’s Azure AD Connect: Upgrade from a previous version to the latest for the full process, as well as Microsoft’s Import and export Azure AD Connect configuration settings.

As always, I highly recommend having an “Alternative Admin” account on your Azure AD. If you lose the ability to sync or authenticate against Azure AD, you’ll need a local Azure AD admin account to connect and manage and re-establish the synchronization.

May 172020
 
Microsoft Windows Server Logo Image

Today we take it back to basics with a guide on how to create an Active Directory Domain on Windows Server 2019.

These instructions are also valid for previous versions of Microsoft Windows Server.

This video will demonstrate and explain the process of installing, configuring, and deploying a Windows Server 2019 instance as a Domain Controller, DNS Server, and DHCP Server and then setting up a standard user.

I also have a newer guide on How to create an Active Directory Domain on Windows Server 2022!

Check it out and feel free to leave a comment! Scroll down below for more information and details on the guide.

Windows Server 2019: How to Create an Active Directory Domain

Who’s this guide for

No matter if you’re an IT professional who’s just getting started or if you’re a small business owner (on a budget) setting up your first network, this guide is for you!

What’s included in the video

In this guide I will walk you through the following:

  • Installing Windows Server 2019
  • Documenting a new Server installation
  • Configuring Network Settings
  • Installation and configuration of Microsoft Active Directory
  • Promote a server as a new domain controller
  • Installation and configuration of DNS Role
  • Installation and configuration of DHCP Role
  • Setup and configuration of a new user account

What’s required

To get started you’ll need:

Hardware/Software used in this demonstration

  • VMware vSphere
  • HPE DL360p Gen8 Server
  • Microsoft Windows Server 2019
  • pfSense Firewall

Other blog posts referenced in the video

The following blog posts are mentioned in the video:

Oct 072019
 
Microsoft Windows Server Logo Image

Today I’m going to be talking about Read Only Domain Controllers (RODC). An RODC is a Read Only Domain Controller for Active Directory Services inside of Microsoft Windows Server. It has become one of my favorite discoveries in the last 10 years for use with clients in certain situations.

A Read Only Domain Controller is similar to a regular Domain Controller, with the exception that the content is synchronized and available as a read-only copy. You cannot write to an RODC AD database.

Let’s explore RODC’s in more depth and find out what they are, why they are used, and use-case scenario examples.

What is an RODC

Read Only Domain Controllers were originally released with Windows Server 2008, and have been available on all versions since (including Windows Server 2008R2, Windows Server 2012/2012R2, Windows Server 2016, and Windows Server 2019).

A Domain controller that is an RODC contains a read-only cached copy of the Active Directory database. Additional sets of controls are available to control and limit this information and what is stored and cached.

Why an RODC

A Read Only Domain Controller is typically placed in situations and scenarios where a standard writable domain controller cannot be placed. The AD data/information can be filtered so that important items such as passwords, credentials, and other security sensitive information are not cached on that server. This provides a safety mechanism if the RODC is stolen or compromised (either physically, or virtually). You can control it so that only required information is cached, such as credentials for the users in the specific office.

RODC’s are meant to be used at remote offices and/or branch offices (ROBO) to allow services to function that rely on Active Directory such as file/print services and other Active Directory applications. Also, typically at these sites it either wouldn’t make sense or be safe to have a writable domain controller, however the RODC is needed to cache AD information, and enhance performance of these AD applications.

Offloading Active Directory requests to a single cached copy onsite on an RODC significantly reduces bandwidth pipe requirements versus having numerous computers and users authenticating and requesting Active Directory content over a site-to-site VPN between the main office and remote office/branch office.

Also, if you have an office with an unstable internet connection where the site-to-site VPN regularly has issues or isn’t always available, having an RODC available to handle Active Directory requests can keep that office online and functioning.

Scenarios for an RODC

In the past I’ve used Read Only Domain Controllers for a few different types of scenarios. I’ll get in to them below and explain why.

The scenarios:

  • AD Cache for ROBO (Remote Office Branch Office)
    • Unstable internet connection
    • AD Services at remote site (File/Print, LoB)
    • Numerous Users accessing Active Directory
    • Improve login times
  • ROBO with Potential Security issues (theft, lack of survailence, etc.)
    • Office is in remote area with delayed physical security response, risk of theft
    • Server physical security at risk, employees could have access
  • Corporate Infrastructure hosted in the Cloud
    • Domain Controller in the Cloud
    • Need a DC on-premise to handle logins and resource access

AD Cache for ROBO (Remote Office Branch Office)

Implementing an RODC in this situation is an excellent example. In a situation where an office has unreliable (intermittent or slow) internet but is critical to business continuity, an RODC can keep them up and running uninterrupted.

Typically, if you were just using a Site-to-Site VPN, if that connection went down, users wouldn’t be able to authenticate against Active Directory or access resources in Active Directory. Having an RODC on-site, allows them to authenticate (if their credentials are stored) and access resources.

As most IT professionals are aware, having a large number of users authenticating and accessing these resources over a VPN can use up the bandwidth pipe and cause issues. Having an RODC locally virtually eliminates VPN bandwidth usage to only Active Directory synchronization, and synchronization deltas.

Finally, having users authenticate locally instead of a saturated high latency VPN connection, improves their login time and performance.

ROBO with Potential Security issues (theft, lack of survailence, etc.)

If you have a remote site with security concerns, an RODC can help you with your security strategy.

If an RODC is physically stolen, only credentials that are filtered to be cached on that RODC are stored locally, this usually excludes administrative accounts as well as other users and services that aren’t accessed or used at the remote site. Also, because the domain controller isn’t writable, the thief cannot power on, inject data in to Active Directory and have it sync to your other domain controllers if they somehow gained access to your internal network.

The above also holds true for possible malicious employees who may have skills or knowledge, or allow other 3rd parties to have physical or virtual access to the server.

In the event of a disaster, restoring or recreating an RODC is easy and fast. Since it synchronizes from writable DCs on the network, the concerns of traditional writable domain controller restores don’t need to be considered.

Corporate Infrastructure hosted in the Cloud

If by chance most of your corporate infrastructure is hosted in the cloud, you know that you still need some on-premise resources and infrastructure to handle and offload bandwidth requirements between your LAN network and virtual cloud LAN network.

Typically, in most cases you’d have an on-site on-premise domain controller to handle local login and authentication, as well as resource access. But why use a fully writable domain controller, when you can use an easy to manage and maintain RODC?

Using an RODC at your local site allows you to offload services off the pipe, to the RODC, again limiting bandwidth requirements to AD synchronizations and delta synchronizations. This allows your bandwidth to be used for more important things like Line of Business applications, e-mail, etc.

As most IT professionals prefer simple and functional, this keeps simplified and easy to manage.

Conclusion

RODC’s are a perfect tool to compliment your IT infrastructure and help secure it as well. I’ve placed numerous Read Only Domain Controllers at customers branch offices, remote oil and gas sites, and in various other scenarios.

Not only have they kept these customers up and running during outages, but the ease of use and ease of management make it common sense to use this technology.

Oct 162018
 

In this post, I’ll be going over how to add additional and/or alternative UPN suffixes to your Active Directory. I’ll also be going over why you may require this inside of your environment.

This is also a follow up post to the article here: https://www.stephenwagner.com/2016/09/23/outlook-2016-exchange-2013-password-prompts-upn-and-samaccountname-troubles/ as Microsoft has deleted the KB 243629 article which contained the original instructions.

Why

There is a number of reasons why you may want to do this:

  1. You’re migrating to a newer version of Microsoft Outlook 2016, and require the users UPN to match the users e-mail address for auto-configure to function.
  2. Your internal domain is is a “domain.local” domain, however you want users to log in with a “domain.com” domain.
  3. You are implementing a line of business application or other piece of software that requires user’s UPNs to match their e-mail addresses.
  4. You’re performing a migration.

How

Let’s get to it! Here’s how to add an alternative UPN suffix to an Active Directory domain:

  1. Log on to your domain controller.
  2. Open “Active Directory Domains and Trusts”
  3. On the left hand side of the new window, right click on “Active Directory Domains and Trusts”, and select “Properties” (as shown below).

    Active Directory Domains and Trusts Window

    Active Directory Domains and Trusts Window

     

  4. Type in your new domain suffix in to the “Alternative UPN suffixes” box, and then click “Add”. As shown below.

    Add Alternative UPN suffix

    Add Alternative UPN suffix

     

  5. Click “Apply” and then close out of the windows.

The new UPN suffix should be available via “Active Directory Users and Computers” and you should be able to set it to users.

You can also configure the user accounts via the Exchange Administration Center (EAC). See below for an example:

Exchange Administration Center UPN Suffix

Exchange Administration Center UPN Suffix

 

Oct 182017
 

Well, it’s October 18th 2017 and the Fall Creators update (Feature update to Windows 10, version 1709) is now available for download. In my particular environment, I use WSUS to deploy and manage updates.

Update: It’s now May 2018, and this article also applies to Windows 10 April 2018 update version 1803 as well!

Update: It’s now October 2018, and this article also applies to Windows 10 October 2018 update version 1809 as well!

Update: It’s now May 2019, and this article also applies to Windows 10 May 2019 update version 1903 as well!

I went ahead earlier today and approved the updates for deployment, however I noticed an issue on multiple Windows 10 machines, where the Windows Update client would get stuck on Downloading updates 0% status.

I checked a bunch of things, but noticed that it simply couldn’t download the updates from my WSUS server. Further investigation found that the feature updates are packaged in .esd files and IIS may not be able to serve these properly without a minor modification. I remember applying this fix in the past, however I’m assuming it was removed by a prior update on my Windows Server 2012 R2 server.

If you are experiencing this issue, here’s the fix:

  1. On your server running WSUS and IIS, open up the IIS manager.
  2. Expand Sites, and select “WSUS Administration”
  3. On the right side, under IIS, select “MIME Types”
  4. Make sure there is not a MIME type for .esd, if there is, you’re having a different issue, if not, continue with the instructions.
  5. Click on “Add” on the right Actions pane.
  6. File name extension will be “.esd” (without quotations), and MIME type will be “application/octet-stream” (without quotations).
  7. Reset IIS or restart WSUS/IIS server

You’ll notice the clients will now update without a problem! Happy Updating!