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!

Sep 232016
 

There’s quite a few of us that started off deploying Small Business Server (SBS2008, SBS2011) environments back in the day, loving the handy all-in-one package taking care of everything from Active Directory and Exchange, to disaster recovery and business continuity. However, some of these old environments are starting to catch up with us. I wanted to open a discussion on a big issue I had a couple years ago in one of my first migrations from SBS 2008, to Windows Server 2012 R2 with the Essentials Experience role installed, with Exchange Server 2013.

As most of you know, SBS comes packaged to push “.local” domains on initial domain configuration. This used to be considered best practice, and most of us even configured .local’s on non-SBS environments. This has never really posed any problems for us I.T. guys, except for a few configuration considerations when setting up Outlook clients, DNS, etc…

Now if you’re like me, another thing I always configured, was user accounts that didn’t match e-mail addresses. An example would be “John Doe”, with the username of “JohnD”, and the e-mail address of “[email protected]”. Also, our buddy John Doe would have a AD UPN [email protected] (this was automatically populated on user setup)

User’s Name: John Doe

SAM Account Name: INTERNALDOMAIN\JohnD

Username: JohnD

AD UPN: [email protected]

E-mail Address: [email protected]

 

I always liked this as it provided some protection if the users password ever got compromised (in a phishing attack, fake e-mail logon page, etc…), as the password could not actually authenticate when using the e-mail address as a username (the username was never actually provided in the attack, only e-mail).

Now let’s flash forward to this migration from SBS 2008, to Windows Server 2012 R2 with Essentials Experience, and throw Exchange 2013 in to the mix. Right off the bat, everything is working fine, Outlook 2010 is working great, Outlook 2013 is working great. Then BAM, Outlook 2016 comes out!

Outlook 2016 does not allow manual or custom configuration of Exchange accounts. They do this for “reliability” and ease of configuration. This means that you HAVE to have autodiscover setup, and working fluidly. No more manual configuration. Internally inside of the LAN this is all automatic if you configured Exchange properly, but you will have to configure autodiscover externally.

Internally on the LAN, Outlook 2016 clients have absolutely no issues, and authentication is working fine (no password prompts). However, when configuring external users, while you can eventually get it configured, the user is constantly prompted for credentials on every Outlook start.

On these password prompts, you’ll notice it’s authenticating for the users e-mail address. In this example, it’s asking for “[email protected]” and you enter: “INTERNALDOMAIN\JohnD” and their password, it work for the session, but keeps prompting on every fresh Outlook start.

I did massive amounts of research and seriously I could not come across one article that actually provided all the information I needed, it almost seemed as if this problem was specific to this single environment. Of course, this makes me think I have something configured incorrectly, and I literally spend forever searching for information, checking my VirtualDirectories on my Exchange server, checking logs, wasting tons and tons of time.

Finally after checking my configurations 6-10 times each and spending weeks, I realized it had nothing to do with anything configured incorrectly.

Outlook 2016 does all the configuration automatically, and expects to find everything it needs via auto discover. Putting it simple, the user’s UPN must match their e-mail address.

This means we have to change John Doe’s Active Directory UPN to match his e-mail address. The SAMAccountName still remains the same, so his login to his computer will not change, however after the change he will now be able to log in both with INTERNALDOMAIN\JohnD and [email protected].

First we have to add the UPN suffix (which is the actual e-mail address domain name) to the Active Directory Domain and Trusts. Instructions are available here: https://support.microsoft.com/en-us/kb/243629. Please note Microsoft has since deleted the original knowledge base article so I created a blog post to outline the instructions here: https://www.stephenwagner.com/2018/10/16/how-to-add-an-alternative-upn-suffix-to-an-active-directory-domain/.

After adding your e-mail domain to the UPN suffix list. When you go in to “Active Directory Users and Computers”, and view a user’s properties, you’ll notice in the UPN section, you can drop it down and change it from internaldomain.local, to contoso.com (using my example domains). You can also change the username inside of the UPN.

 

Essentially for Johny boy, his AD properties window now looks like:

User Logon Name:

[email protected] (we changed the name, and chose the external domain in the drop down to the right)

User logon name (pre-Windows 2000):

INTERNALDOMAIN\ JohnD (we left this the way it was)

 

John can now login either using “INTERNALDOMAIN\JohnD” or “[email protected]”. As far as John is concerned we haven’t changed anything and he still logs in using the same format he always has, totally unaware of any changes.

Surprise surprise, autodiscover is now fully functioning for this user. Not only for easy configuration on mobile devices (iPhones, Windows Phones, etc…), but he can now load up Outlook 2016 away from the LAN on the Internet, type in his e-mail address, password, and BAM he’s good to go!

I am a little bit unsettled in the fact that the e-mail address now becomes a fully accepted username on the domain (for security reasons), but I guess we’re stuck with that!

 

In short, our problem is:

  1. Username doesn’t match e-mail (JohnD username, [email protected] email)
  2. Running Outlook 2016 and forced to use auto-discover, repeated password prompts
  3. Running .local domain internally, while using different domain externally

In Short, to fix this:

  1. Add UPN Suffix to Active Directory
  2. Change users properties so that UPN matches e-mail address, DO NOT CHANGE the old DOMAIN\Username setting

Other Considerations:

  1. Password prompts on Outlook clients can mean a whole bunch of different problems totally unrelated to this configuration and issue. Always fully diagnose the issue and confirm the issue before applying fixes. Password prompts can mean authentication problems, problems with Exchange’s virtualdirectories, issues with autodiscover, issues with certificate configuration, etc…
  2. If this is your specific issue, you can write a script to run through and update the UPNs on all the accounts. I generally don’t like scripts touching user accounts, so I’m slowly rolling out these changes per user when upgrading them to Outlook 2016. Doing this one by one as we upgrade, allows us to make sure that none of their mobile devices are affected by the UPN change.
  3. Since we are changing UPNs, this could have a major effect on any 3rd party applications that integrate with Active Directory that use UPNs. Always test, and make sure you don’t break any integration points to your 3rd party applications or line of business systems.

 

May 312013
 

Back in February, I was approached by a company that had multiple offices. They wanted my company to come in and implement a system that allowed them to share information, share files, communicate, use their line of business applications, and be easily manageable.

Just an FYI, I provide Microsoft Small Business Server consulting services, including migrations! For more information, please visit https://www.stephenwagner.com/2020/02/28/microsoft-small-business-server-migration-upgrade/.

The Solution – Microsoft Small Business Server 2011

The first thing that always comes to mind is Microsoft Small Business Server 2011. However, what made this environment interesting is that they had two branch offices in addition to their headquarters all in different cities. One of their branch offices had 8+ users working out of it, and one only had a couple, with their main headquarters having 5+ users.

Usually when administrators think of SBS, they think of a single server (two server with the premium add-on) solution that provides a small business with up to 75 users with a stable, enterprise feature packed, IT infrastructure.

SBS 2011 Includes:

  • Windows Server 2008 R2 Standard
  • Exchange Server 2010
  • Microsoft SharePoint Foundation 2010
  • Microsoft SQL Server 2008 R2 Express
  • Windows Server Update Services
  • (And an additional Server 2008 R2 license with Microsoft SQL Server 2008 R2 Standard if the premium add-on is purchased)

Essentially this is all a small business typically needs, even if they have powerful line of business applications.

Additional Domain Controller on SBS

One misconception about Windows Small Business Server is the limitation of having a single domain controller. IT professionals often think that you cannot have any more domain controllers in an SBS environment. This actually isn’t true. SBS does allow multiple domain controllers, as long as there is a single forest, and not multiple domains. You can have a backup domain controller, and you can have multiple RODCs (Read Only Domain Controller), as long as the primary Active Directory roles stay with the SBS primary domain controller. You can have as many global catalogs as you’d like! As long as you pay for the proper licenses of all the additional servers 🙂

This is where this came in handy. While I’ve known about this for some time, this was the first time I was attempting at putting something like this in to production.

The Plan

The plan was to setup SBS 2011 Premium at the HQ along with a second server at the HQ hosting their SQL, line of business applications, and Remote desktop Services (formerly Terminal Services) applications. Their HQ would be sitting behind an Astaro Security Gateway 220 (Sophos UTM).

The SBS 2011 Premium (2 Servers) setup at the HQ office will provide:

  • Active Directory services
  • DHCP and DNS Services
  • Printing and file services (to the HQ and all branch offices)
  • Microsoft Exchange
  • “My Document” and “Desktop” redirection for client computers/users
  • SQL DB services for LoB’s
  • Remote Desktop Services (Terminal Services) to push applications out in to the field

The first branch office, will have a Windows Server 2008 R2 server, promoted to a Read Only Domain Controller (RODC), sitting behind an Astaro Security Gateway 110. The Astaro Security Gateway’s would establish a site-to-site branch VPN between the two offices and route the appropriate subnets. At the first branch office, there is issues with connectivity (they’re in the middle of nowhere), so they will have two internet connections with two separate ISPs (1 line of sight long range wireless backhaul, and one simple ADSL connection) which the ASG 110 will provide load balancing and fault tolerance.

The RODC at the first branch office will provide:

  • Active Directory services for (cached) user logon and authentication
  • Printing and file services (for both HQ and branch offices)
  • DHCP and DNS services
  • “My Documents” and “Desktop” redirection for client computers/users.
  • WSUS replica server (replicates approvals and updates from WSUS on the SBS server at the main office).
  • Exchange access (via the VPN connection)

Users at the first branch office will be accessing file shares located both on their local RODC, along with file shares located on the HQ server in Calgary. The main wireless backhaul has more then enough bandwidth to support SMB (Samba) shares over the VPN connection. After testing, it turns out the backup ADSL connection also handles this fairly well for the types of files they will be accessing.

The second branch office, will have an Astaro RED device (Remote Ethernet Device). The Astaro/Sophos RED devices, act as a remote ethernet port for your Astaro Security Gateways. Once configured, it’s as if the ASG at the HQ has an ethernet cable running to the branch office. It’s similar to a VPN, however (I could be wrong) I think it uses EoIP (Ethernet over IP). The second branch doesn’t require a domain controller due to the small number of users. As far as this branch office goes, this is the last we’ll talk about it as there’s no special configuration required for these guys.

The second branch office will have the following services:

  • DHCP (via the ASG 220 in Calgary)
  • DNS (via the main HQ SBS server)
  • File and print services (via the HQ SBS server and other branch server)
  • “My Document” and “Desktop” redirection (over the WAN via the HQ SBS server)
  • Exchange access (via the Astaro RED device)

Hardware

For all the servers, we chose HP hardware as always! The main SBS server, along with the RODC were brand new HP Proliant ML350p Gen8s. The second server at the HQ (running the premium add-on) is a re-purposed HP ML110 G7. I always configure iLo on all servers (especially remote servers) just so I can troubleshoot issues in the event of an emergency if the OS is down.

Implemenation

I’ll explain how this was all implemented.

  1. Configure and setup a typical SBS 2011 environment. I’m going to assume you already know how to do this. You’ll need to install the OS. Run through the SBS configuration wizards, enable all the proper firewall rules, configure users, install applicable server applications, etc…
  2. Configure the premium add-on. Install the Remote Desktop Services role (please note that you’ll need to purchase RDS CAL’s as they aren’t included with SBS). You can skip this step if you don’t plan on using RDS or the premium server at the main site.
  3. Configure all the Astaro devices. Configure a Router to Router VPN connection. Create the applicable firewall rules to allow traffic. You probably know this, but make sure both networks have their own subnet and are routing the separate subnets properly.
  4. Install Windows Server 2008 R2 on to the target RODC box (please note, in my case, I had to purchase an additional Server 2008 license since I was already using the premium add-on at the HQ site. (If you purchase the premium add-on, but aren’t using it at your main office, you can use this license at the remote site).
  5. Make sure the VPN is working and the servers can communicate with each other.
  6. Promote the target RODC to a read only domain controller. You can launch the famous dcpromo. Make sure you check the “Read Only domain controller” option when  you promote the server.
  7. You now have a working environment.
  8. Join computers using the SBS connect wizard. (DO NOT LOG ON AS THE REMOTE USERS UNTIL YOU READ THIS ENTIRE DOCUMENT)

I did all the above steps at my office and configured the servers before deploying them at the client site.

You essentially have a working basic network. Now to get to the tricky stuff! This tricky stuff is to enable folder redirection at the branch site to their own server (instead of the SBS server), and get them their own WSUS replica server.

Now to the fancy stuff!

1. Installing WSUS on the RODC using the add role feature in Windows Server: You have to remember that RODC’s are exactly what they say! !READ ONLY! (As far as Active directory goes)! Installing WSUS on a RODC will fail off the bat. It will report that access is denied when trying to create certain security groups. You’ll have to manually create these two groups in Active Directory on your primary SBS server to get it to work:

  • SQLServer2005MSFTEUser$RODCSERVERNAME$Microsoft##SSEE
  • SQLServer2005MSSQLUser$RODCSERVERNAME$Microsoft##SSEE

Replace RODCSERVERNAME with the computer name of your RODC Server. You’ll actually notice that two similiar groups already exist (with the server name different) for the existing Windows SBS WSUS install, this existing groups are for the main WSUS server. After creating these groups, this will allow it to install. After this is complete, follow through the WSUS configuration wizard to configure it as a replica for your primary SBS WSUS server.

2. One BIG thing to keep in mind is that with RODC’s you need to configure what accounts (both user and computer) are allowed to be “cached”. Cached credentials allow the RODC to authenticate computers and users in the event the primary domain controller is down. If you do not configure this, if the internet goes down, or the primary domain controller isn’t available, no one will be able to log in to their computers or access network resources at the branch site. When you promoted the server to a RODC, two groups were created in Active Directory: Allow RODC Cached Logins, and Deny RODC Cached Logins (I could be wrong on the exact name since I’m going off memory). You can’t just select and add users to these groups, you need to also select and add the computers they use as well since computers have their own “computer account” in Active Directory.

To overcome this, create two security groups under their respective existing groups. One group will be for users of the branch office, the other group will be for computers of the branch office. Make sure to add applicable users and groups as members of the security groups. Now go to the “Allow RODC Cached Logins” group created by the dc promotion, and add those two new security groups to that group. This will allow remote users and remote computers to authenticate using cached security credentials. PLEASE NOTE: DO NOT CACHE YOUR ADMINISTRATIVE ACCOUNT!!! Instead, create a separate administrative account for that remote office and cache that.

3. One of the sweet things about SBS is all the pre-configured Group policy objects that enable the automatic configuration of the WSUS server, folder redirection, and a bunch of other great stuff. You have to keep in mind that off of the above config, if left alone up to this point, the computers in the branch office will use the folder redirection settings and WSUS settings from the main office. Remote users folder redirection (whatever you have selected, in my case My Documents and Desktop redirection) locations will be stored on the main HQ server. If you’re alright with this and not concerned about the size of the user folders, you can leave this. What I needed to do (for reasons of simple disaster recovery purposes) is have the folder re-directions for the branch office users store the redirection on their own local branch server. Also, we need to have the computers connect to the local branch WSUS server as well (we don’t want each computer pulling updates over the VPN connection as this will use up tons of bandwidth). What’s really neat is when users open applications via RemoteApp (over RDS), if they export files to their desktop inside of RemoteApp, it’ll actually be immediately available on their computer desktop since the RDS server is using these GPOs.

To do this, we’ll need to duplicate and modify a couple of the default GPOs, and also create some OU (Organizational Unit) containers inside of Active Directory so we can apply the new GPOs to them.

First, under “SBSComputers” create an OU called “Branch01Comps” (or call it whatever you want). Then under “SBSUsers” create an OU called “Branch01Users”. Now keep in mind you want to have this fully configured before any users log on for the first time. All of this configuration should be done AFTER the computer is joined (using the SBS connect) to the domain and AFTER the users are configured, but BEFORE the user logs in for the first time. Move the branch office computer accounts to the new Branch office computers OU, and move the Branch office user accounts to the Branch office users OU.

Now open up the Group policy Management Management Console. You want to duplicate 2 GPOs: Update Services Common Settings Policy (rename the duplicate to “Branch Update Services Common Settings Policy” or something), and Small Business Server Folder Redirection Policy (rename the duplicate to “Branch Folder Redirection” or something).

Link the new duplicated Update Services policy to the Branch Computers OU we just created, and link the new duplicated folder redirection to the new users policy we just created.

Modify the duplicated server update policy to reflect the address of the new branch WSUS replica server. Computers at the branch office will now pull updates from that server.

As for Folder redirection, it’s a bit tricky. You’ll need to create a share (with full share access to all users), and then set special file permissions on the folder that you shared (info available at http://technet.microsoft.com/en-us/library/cc736916%28v=ws.10%29.aspx). On top of that, you’ll need to find a way to actually create the child users folders under that share/folder in which you created. I did this by going in to active directory, opening each remote user, and setting their profile variable to the file share. When I hit apply this would create a folder with their username with the applicable permissions under that share, after this was done, I would undo that variable setting and the directory created would stay. Repeat this for each remote user at that specific branch office. You’ll also need to do this each time you add a new user if they bring on more staff, you’ll also need to add all new computers and new users to the appropriate OUs, and security groups we’ve created above.

FINALLY you can now go in to the GPO you duplicated for Branch Folder redirection. Modify the GPO to reflect the new storage path for the redirection objects you want (just a matter of changing the server name).

4. Configure Active Directory Sites and Services. You’ll need to go in to Active Directory Sites and Services and configure sites for each subnet you have (you main HQ subnet, branch 1 subent, and branch 2 subnet), and set the applicable domain controller to those sites. In my case, I created 3 sites, and configured the HQ subnet and second branch to authenticate off the main SBS PDC, and configured the first branch (with their own RODC) to authenticate off their own RODC. Essentially, this tells the computers which domain controller they should be authenticating against.

And you’re done!

A few things to remember, whenever adding new users and/or computers to the branch, ALWAYS join using SBS wizard, add computer to the branch OU, add user to the branch OU, create the users master redirection folder using the profile var in the AD user object, and separately add both user and computer accounts as members of the security group we created to cache credentials.

And remember, always always always test your configuration before throwing it out in to production. In my case, I got it running first try without any problems, but I let it run as a test environment for over a month before deploying to production!

We’ve had this environment running for months now and it’s working great. What’s even cooler is how well the Astaro Security Gateway (Sophos UTM) is handling the multiple WAN connections during failures, it’s super slick!

Apr 222010
 

Recently with the new vulnerabilities with Java, I needed to push the latest Java update remotely to all of my clients currently using my companies “Managed Services”.

The upgrade was being scheduled for certain dates per location, however as of Tuesday morning I noticed that some computers were being hit with some of the newer vulnerabilities recently discovered.

This all of a sudden changed the priority from “high priority” to “emergency”. I needed a  quick and efficient means of pushing this update to computers at client sites.

Active Directory allows system administrators to push, allow, or make available software installations to users. This is all controlled inside of Active Directory Group Policy Management.

To push the latest Java update to all computers on a network, I had to perform the steps below:

1. Download the “Offline Installation” of Java from the Java website. Open the file, do not proceed to continue the installation. (You will simply hit cancel after you extract the MSI and other files needed).

2. Open a explorer and browse to C:\Users\%USERNAME%\AppData\LocalLow\Sun\Java\jre1.6.0_20. After navigating to this location copy “Data1.cab”, “jre1.6.0_20.msi”, and “sp1033.MST” to a new folder (I chose a folder on my desktop).

3. Log into the remote server, create a file share (for example NetInstall), and configure users read access only.

4. Copy the folder you created on your desktop to the new file share on the server. Remember to use a naming scheme for the applications you wish to push so that they all make sense and can be organized.

5. On the server, go to Start -> Administrative Tools -> Group Policy Management

6. Either create a new GPO, or use an existing on that you have configured. If you are unfamiliar with this, it may be worth while doing some online research on GPOs. In my case I right clicked, and chose edit on the “Windows SBS Client Policy” GPO on SBS 2008.

7. Expand Computer Configuration, policies, Software Settings, Software installation. Right click on “Software Installation” and select new package. Follow the instructions.

8. When choosing the location of the .msi file, PLEASE make sure that you browse to it using your UNC network path. This location has to be somewhere where all the computers have access to. (I.E. don’t use C:\Folder\file.msi, you would rather use \\servername\sharename\programname\file.msi).

At this point you have now configured the server to force install Java on all the computers that apply to that GPO. This is perfect to make sure that all your clients are running the latest versions of free software available. It will also help with managing vulnerabilities with aging software, etc…

Please note: If this doesn’t work right away it is because the client workstations need to refresh their GPO. After the GPO is refreshed on the client workstation side, the system should install the package on next reboot.

There are some other neat things you can do with GPOs, and pushing applications on your network, however I’m not covering it in this document. For example instead of using “Computer Configuration”, you could use “User Configuration”, and instead of forcing applications you could actually make applications available for install through “Add/Remove Programs” for users to install.

Please always make sure that any applications you use are properly paid for and/or licensed.