Migrating Certificate Services from Server 2012 R2 to Server 2019, the right way.

So firstly, it’s been about 4 years since my last blog post so I think an apology is in order. Honestly I thought the Ubuntu Server GuestVM I had this site running on was deleted years ago when I moved house. Turns out it wasn’t and I just had it mis-configured it with the wrong DNS settings (Reverse Proxy; yada, yada, yada). I can’t believe this server has been here all this time with no one (including myself) ever seeing it, particularly when I’m always periodically looking at my Hyper-V console.

Anyways, as the title suggests I’m currently in the midst of a server refresh, because you know, you have to do that everyone once and a while. This task in-particular is for Active Directory Certificate Services and moving it to Server 2019 Core.

The server I’m moving from is Server 2012 R2 Core. So you can already get a sense the instructions that everyone uses because it works with any edition of Window Server wont work here because yep, I don’t have a GUI. I shouldn’t need to tell you why in 2019, Server GUI is a bad, lazy way to so Server stuff

Because I’m already running a SHA256 root CA the process is a bit more straight forward. If for whatever you’re still running SHA1, then I’d suggest move the Certificate Services database first then do the changes and certificate reissue for the new root. Tip: The GUI steps in this link are done command line below!

So let’s start with building our new Server 2019. Get the operating installed and go ahead and join it to the domain. On top of those, install the like-for-like Certificate Services role from the old server on the new server but don’t configure them just yet! You can easily do a side-by-side comparison with running “Get-WindowsFeature” on the old and then just installing those roles with “Install-WindowsFeature” on the new.

When your new server has the new roles, Server Manager will show it like this. Leave it as is.

Moving onto the Root Certificate and Certificate Service Database backup phase now. Get onto your old server and start up an administrative PowerShell window (TIP: just type powershell.exe). Run the following PS cmdlets:

cd C:\
mkdir C:\CertificateServicesBackup
Backup-CARoleService c:\CertificateServicesBackup -Password (Read-Host -prompt "Password:" -AsSecureString)

When prompted, provide a password that you’ll remember. You’ll need it later.


Okay, so backup of Certificate Root and Database done, now to backup some important registry settings. In the same PS window, lets backup the important registry now.

reg export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc C:\CertificateServicesBackup\backup.reg

Great! Now take a copy of the C:\CertificateServicesBackup folder and keep it safe, maybe even on the new server. (TIP: “xcopy /e /s C:\CertificateServicesBackup \\newserver.fqdn.com\c$”)

At this point we’ve got what we need, everything is backed up. Now for what people would think is the scary bit and that’s the removal of the old server! This is an important step because doing this later, not at all or after the migration will seriously screw up Active Directory… so don’t do that. Let’s remove it now and be done with it.

Safely remove the old certficate server roles with the “Remove-WindowsFeature” cmdlet. Once that’s done, remove the server from domain.

Now it’s onto the new. With Server Manger or Windows Admin Center lets now click that link to complete the set up we said we would never touch. Tricked you! Go through the wizard until you get to this screen…

Look familiar? It should, because we’re following the same step as the everyone uses blog!

As the everyone uses blog article suggests, we’re going to provide an existing certificate and private key (protected by password). That certificate is the one you backed up earlier and the password you remembered.

Now, continue through the wizard with all the defaults, including the questions about the database to use as we’ll restore over the new database with the backed up data. When the wizard is done, jump onto the server and launch an administrative PowerShell window again. This time we’re running the restore PS cmdlet.

Restore-CARoleService c:\CertificateServicesBackup -Password (read-host -prompt "Password:" -AsSecureString) -Force 

Again the password is the one we remembered. With that done, we just needed to import the registry settings in. Before you do this, I suggest you open the .reg file in notepad.exe and just check to make sure there is no FQDN’s, Hostnames or IP’s that need updating. If they do, so that before import the registry file by running the below.

reg import HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc C:\CertificateServicesBackup\backup.reg

At this point you’re basically done! I’d restart the service and make sure it comes back up.

Restart-Service certsvc
Get-EventLog (for errors)

Your last task is to re-issue your certificate templates into Active Directory. Easy to just do this with the certsrv.msc management console go to “Certificate Templates (right click) > New > Certificate Template to issue”

The last step! Hooray!

That’s it from me, have a splendid day!



Windows 10 1511 update on WSUS error (Retry Loop)

A quick post today for those who may be struggling with WSUS and Windows 10 1511 updates. It turns out there is one missing component/ step in order to get WSUS to deliver these new type of updates.
Lets assume you are the administrator, knowing enough about WSUS to have already completed the following:
  1. On the WSUS server(s), running Windows Server 2012 or later, installed the required manual update. https://support.microsoft.com/en-us/kb/3095113
  2. On the same WSUS server(s), made appropriate changes to see Upgrade classification patches from the Windows catalog.
  3. Have approve the appropriate Windows 10 1511 Upgrade patches and have them successfully download onto the WSUS server(s).
  4. Attempted a client-side Windows Update.
On step 4, non-1511 Windows 10 client are seeing this error with a simply retry button.
There were problems installing some updates, but we'll try again later. If you keep seeing this and want to search the web or contact support for information, this may help:
The solution comes from a bit of digging in the WindowsUpdate.log/ Get-WindowsUpdateLog. It appears that the Windows update client is unable to find a file with the suffix *.esd. For me this was 6F5CDF12827FAE0E37739F3222603EAF38808H12.esd.
Looking at the WSUS server, and in particular the IIS component of WSUS I could see this file was in fact in the directory so the client should get it… Hrmm, let's try the direct URL to the file, ah! 404! That's no good.
Let's check the MIME types to see if this file type can be downloaded from IIS. Nope! IIS is unable to dish out the file because *.esd files are a new MIME type that is not configured in IIS.
Okay, I'll quickly add this and give it another go.



Sure enough success!


Exchange 2007 and 2013 environment – Public Folders on 2007 “Get-PublicFolder” cmdlet fails.

Recently I was tasked with a Public Folder migration project moving the public folders from Exchange 2007 to 2013. This particular company had been on Exchange 2013 for pretty much everything except Public Folders for well over a year which provides a good segue into this issue! When the administrators tried to manage Public Folders on Exchange 2007 they're were getting no where! Both the Exchange 2007 Public Folders Management Console would not load any of the public folders (500+ of them) and the Get-PublicFolder cmdlet would fail with:

There is no existing PublicFolder that matches the following Identity: '\'. Please make sure that you specified the correct PublicFolder Identity and that you have the necessary permissions to view PublicFolder.

Yikes! Well that's no good! So how is it possible that PublicFolders are online and working for end users yet the administrators can't manage them! Let the investigation begin. Funnily enough “Get-PublicFolderStatistics” still worked!

After talking to the engineers previously tasked with the migration to Exchange 2013 work, it was when the last remaining mailbox database in Exchange 2007 was removed that Public Folders management broke. This immidiately led me to believe either one of two things:

  1. It's a permission issue with the administrative accounts they're using.
  2. Something isn't quite right with objects in AD referencing Public Folders in Exchange 2007.

After a quick look around I confirmed that while the permissions for managing Exchange infrastructure was a bit all over the place, it wouldn't have been the root cause. Their accounts had the right permissions to Organizational Management and/or the Public Folders Owner security group in AD. 

Taking a dive in AD with ADSI/ LDP (If you're using ADSI, connect with a non-domain admin account to prevent accidental changes) I could again see things were a bit messy with two administrative groups, but everything was in order. The Folder Hierarchy CN was there and its references were correct. 

Hitting TechNet with searches on "Exchange 2007" lead me to issues around the HomeMDB being nulled when the last mailbox database is removed for each Exchange 2007 server for the Microsoft System Attendant object. Sure enough this attribute was null so I immediately tested by creating a new fresh Exchange 2007 mailbox database to see if that was the issue. HomeMBD was instantly populated for the Microsoft System Attendant object when I created the databases but alas, still the above issue! 

At this point I was really clutching at straws and therefore started checking the ‘interwebs’ and found all sorts of whacky recommendations and fixes! There are some shockers out there and it does scare me that someone with no background experience in Exchange/ AD could follow them and make a real mess of their environment. Sadly, you can't help those who can't help themselves! 

None of them really fitted well with the issue I had and/ or made practical sense to even action. So with that in mind I made a call to Microsoft.

After a bit of coming and going as you do with Microsoft tier 1 support the suggestion was to populate the Exchange 2013 servers Microsoft System Attendant object with a HomeMDB attribute to the Exchange 2007 mailbox databases. As you can appreciate with my comments already above I found this a bit baffling and refuted it. However that didn’t stop me from looking at it a bit more…

On one of the Exchange 2007 Servers I got going the troubleshooting tool and selected trace control. From there I proceeded beyond the warning messages about running traces when only recommended by an Exchange support engineer.


Leaving all the trace file configuration pretty much default, I did want to capture only Store trace errors (similar to https://support.microsoft.com/en-us/kb/971878) so I made this selection. For trace types I selected all of them.

For the trace tags, I took a stab in the dark a couple of times to see what I wanted to check against. After much trial and error I got it down to three which found me the issue…. These were:

  • tagDSError
  • tagInformation
  • tagRpcIntfLogon



While the trace was running I then opened up an Exchange 2007 management shell and ran “Get-PublicFolder” to let it fail. Stopping the trace and running the report on the trace highlighted my issue!


tagDSError – Mailbox /o=Y/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=XXX/cn=Microsoft System Attendant, does not have either a Home MDB or a GUID

tagInformation – EcConnect2: User /o=Y/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=XXX/cn=Microsoft System Attendant, does not have a Home MDB/GUID attribute

tagRpcIntfLogon -Connect as /o=Y/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=XX/cn=Microsoft System Attendant failed; connect flags were 0x1


XXX CN was an Exchange 2013 server! Aha, Microsoft tier 1 support are onto something. Okay, well I don’t believe them about the Exchange 2007 mailbox database though! So I thought what’s stopped me putting in an Exchange 2013 mailbox database, at least that way the information would be accurate and not legacy!

So I jumped into ADSI edit this time as Domain Admin and found one of the mailbox databases in Exchange 2013. This is under ADSI -> Configuration -> Services -> Microsoft Exchange -> Administrative Groups -> Exchange Administrative Groups -> Databases. I copied out the DN attribute and then went to each of the Exchange 2013 servers and set the homeMBD as that DN. Note that if you have multiple AD sites to pick a mailbox database local to that sites server.

I gave it 15mins to replicate in AD (that’s the replication time for this client) and run the “Get-PublicFolder” cmdlet and sure enough… it worked! Now we're ready to migrate to Exchange 2013!

That's it for now, until next time.

Invalid namespace – EventID 906 – AD Azure Sync Tool (WAAD)

Today I came across an interesting issue where the AD Azure Sync Tool via Microsoft Online alerted me that AD Azure Sync had failed to run for some time!


This was quite odd as there had been no changes to the Office 365 or AD instances that provide the identity sources for this AD Azure Sync. There were some power outages in their server room that caused a few other services to not come up clean so I thought it could be that the service failed to start etc. Monitoring by SCOM said otherwise though! Okay time for checking the event logs and within a few seconds found this.


Interesting! EventID 906 "Invalid Namespace"… That's the same issues that appeared with the old DIRSYNC.exe when the WMI object had unregistered itself. Common for example if you have SCCM client installed on the server or something else goes through and manipulates the WMI classes probably where it shouldn't be. Okay, let's fix this quickly without having to reinstall anything… Something that you had to do with DIRSYNC.exe. A total pain in the backside, and if you weren't careful, you could have ended up with a boatload of disconnected objects in the metaverse!

At this point I had a choice. Do these steps manually or create a dirty batch script that will do the work for me and if needed in the future, on demand. I decided to do both, ran the steps manually and once I was happy with it, save my work into the batch file for future use!

So below is my script that I first ran the commands or enacted the same thing the script would do with the GUI. Once I actually had it all set up and AD Azure working again, I actually ran the new script again (over the top of my manual work) to confirm that the script was safe. And sure enough, it was and everything was working fine after the script ran.

To break down what the script does here is a list of what each row does. 

  1. 'mofcomp' parses the MMS (FIM) wmi file and goes through the process of adding the classes etc. to the WMI repository.
  2. 'regsvr32' then registers the WMI .dll file to the server.
  3. 'net stop winmgt /y' stops the WMI management services and its dependancies.
  4. The following 'net start' commands then start the services stopped when we fired off the 'net stop'. The services are also started in the correct order.
  5. Finally, we run AD Azure Sync manually by calling "DirectorySyncClientCmd.exe". 
mofcomp "D:\Program Files\Microsoft Azure AD Sync\Bin\mmswmi.mof"
regsvr32 /s "D:\Program Files\Microsoft Azure AD Sync\Bin\mmswmi.dll"

net stop winmgmt /y
net start winmgmt
net start "IP Helper"
net start "User Access Logging Service"
net start "Microsoft Azure AD Sync"

"D:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCmd.exe"

As you can see the directory for which AD Auzre has been installed is the D: drive. You can change this batch file with %Program Files% if you're using your system drive (C:).

That's it from me for now. I hope this helps others in the future using the AD Azure Sync Tool! 

Azure Active Directory (WAAD) Sync Tool – Password Sync issue and the importance of running the entire wizard

Today I came across an interesting find with the Azure AD Sync Tool that I thought I would share. The issue was rather easy to identify but someone with an untrained eye might find it confusing or a little misleading. When I say untrained this article is really for those who may be going alone with an Office 365 migration for the first time for their business or in a test lab… Though the semi-professional administrator may find this interesting.

To give you a bit of history about my knowledge on this, I come from the Forefront Identity Management 2010 (FIM) head space in that when myself and Lain rebuilt a major university's IT infrastructure back in 2010-2011 we didn't have the freedom that comes with Office 365 / Azure AD today. I.e. It was FIM, FIM or, and you've guessed it, FIM. So when we built our management agents and the subsequent metaverse, it was staggered in order so that once everything was in place and we were happy with it, we'd go back and implement Password Change Notification Services (PCNS) as the last step.

Coming back to today however there are three options out there for us to use for directory synchronisation. Those being of course:

  • DirSync. The widely used directory sync tool out there for many clients. It has served its purpose and proven to be a suitable solution for many organisations who just need basic Office 365 attribute flow etc. 
  • Azure AD Sync. The now standard and recommended solution for those looking to directory sync with Azure and Office 365. Those who are about to begin with directory sync this is the current recommended tool by Microsoft. Deter away from using DirSync as the eventual plan for that tool is for it to be put to pasture. The great thing about Azure AD Sync is that it supports multiple AD forests and password write back. Password write back shouldn't be confused with Password Sync by the way! They are two different things with two very different outcomes, especially around security implications!
  • FIM. Lastly FIM is for those who need the ability to customise management agent's (MA's) to the needs of their business. An example where FIM is very powerful is where you have say a HR system (based on say SQL) that flows into an on-premise AD. Meaning your HR system is in fact the definitive source for identity management within your organisation. From AD however you then establish lots of different ADLDS instances for proprietary systems that you might not want talking or bloating AD itself (E.g. Cisco CUCM and Avaya UCM are two strong canidates for ADLDS). Then of course you configure the Office 365 MA and PCNS for provisioning to the Azure cloud.

There is actually a fourth option to this list above but it's only in a Public Preview at the moment. Going by the name AD Azure Connect, this product makes massive inroads for making ADFS federation a hell of a lot easier for the inexperienced administrator. Essentially you only need to provide it with the right certificate and create some DNS records and it configures ADFS for you. It's evident when comparing the four DirSync and Azure AD Sync look somewhat primitive and that Microsoft with this new tool are really pushing the customer base away from Same Sign-On to Single Sign-On (SSO). Unfortunately its hard to compare it with FIM as it is much more powerful in terms of configuration but also to the fact Microsoft haven't really stated what FIM's future is at the moment… I guess we'll know more when AD Azure Connect becomes GA.

So now back to my issue (sorry, got sidetracked). When I was going through the process of installing the Azure AD Sync Tool in a test lab I thought I'd be smart about making sure my metaverse wouldn't be filled up with unnecessary and unneeded objects (User and Groups) from my on-premise AD. When I say unneeded, I don't for example need groups such as "Domain Admins" synchronised to the cloud. Why? Well Office 365 doesn't need them and realistically, neither does your organisation. They for example wouldn't be using "Domain Admins" as a email distribution group and administrative privileges at the Office 365 at least are done at the user level not by groups! Of course you're wanted Lync and Exchange RBAC controls you may have a need for "Domain Admins" but again your probably don't either.

So when it came to the final screen on the wizard I unselected the "Synchronize now" checkbox. No problem as I'll change the filter on my on-premise AD Management Agent first (to pick a subset of OU's) and then run my first Full Import sync on both MA's manually. Done that, great… Now run the first sync by calling the DirectorySyncClientCmd.exe in the install location 'Bin' folder. Done. Awesome! I have got only the users and groups I needed in Azure AD and there is no initial 'disconnectors' in my metaverse. Time to assign licenses and get users on Office 365! 

Now at the point I thought everything was great and I was ready to go… I attempt to login to the Office 365 portal with one of my synchronised accounts but I'm getting told it's not the right username and password combination. Hrmm, turns out I'm not close…. So what's gone wrong?

Well after a quick look at Event Viewer connected to the server running the Azure AD Sync tool I knew my problem straight away…. 


Event 652! But I told the wizard back at Step 4 that I wanted Password Synchronisation. What's going on?!

Well turns out if you choose not to run that first initial sync with the wizard, you're PCNS is not registered on the sever. In a way that does make sense because for PCNS to work you really do need accounts in the cloud to password sync too. But on the other hand it should be able to wait until the first 'Delta Imports and Exports' are run to go, okay, time to grab the password hashes and sync them because there is something there that is new and synced… Much as the case with a new user you create in on-premise AD and eventually syncs to the cloud. For those who don't know PCNS is run completely independent of the the sync tool and the scheduled task I'm about to talk about so I thought that the latter thought of mine would make the most sense. However it's clear with the application event log Microsoft have built the tool in a way that is contrary to that.

So what's the lesson here? Well if you want to change your on-premise AD MA filters before you run the first 'Full Imports' manually you really need to actually kick off the wizard first with 'Password Synchronization' on step 4 (Optional Features) unchecked. Once you've done what you've need to do with the OU filters etc., you need to disable (not delete) the newly created task in Task Schedular, run the wizard again, enable 'Password Synchronization' and save. Again to just remind you, you don't need to run the sync again because PCNS is independent of this. 

Once that's all done, confirm the task as enabled again and if it hasn't, enable it manually. You should find also that your event log is full of Event 657 informing you that PCNS is syncing passwords propery.

Finally and this is just a quick note, if you have gone through the wizard already with Password Synchronisation enabled but you didn't let the wizard run the first sync, then you'll need to add in an additional step prior to the steps above that goes through the wizard first disabling Password Synchronisation. This is because the wizard does not go off and run everything again if it determines there are no changes to be made as you have made any selection changes etc.‚Äč

Happy syncing! 

Microsoft Partner Network – Resell and or offer free trials for Office 365

So this article is going to help those who may be new to the Microsoft Partner Network and want to resell or even just offer free trials to Office 365. I've seen quite a bit of confusion around the internet especially on TechNet about how a partner gains the ability to resell and offer trials so hopefully this article should clear it up and give the necessary steps to get going!

One thing I do want to raise or warn about however is that for someone who doesn't know Office 365 all that well, especially around the licensing options it offers should refrain from trying to resell it or offer free trials on behalf of your organisation until you do. Office 365 is a beast and shouldn't be treated with someone poking it with a stick! Those who are knowledgeable should be the only professionals offering Office 365! You can really hurt your organisation and even the customers if you start offering the wrong licenses etc. 

For those who may not understand licensing, please refer to https://getlicensingready.com/. This portal is very good in providing you with the right tools to tackle Microsoft licensing. 

To begin it's obvious that you'll need to be a Microsoft Partner Network organisation. On top of this you must have completed the competency exam/ test and purchased a Microsoft Action Pack. If you haven't completed your competency exam/ test and subsequently don't have a Microsoft Action Pack you won't be able to resell Office 365. Why? Well the organisation needs Office 365 to resell Office 365 and the only way that is possible without having an Enterprise Agreement or using a reseller like Telstra (Australian customers only) is to be a holder of an Action Pack.

Complete those prerequisites before going on with this article.

Part 1: MOSPA

The first requirement for reselling Microsoft services is to be a member of the Microsoft Online Services Partner Agreement. The following steps should allow you to sign up and register for just that!

  1. First log into the Microsoft Partner Network and view your organisations membership. From there head your "Requirements & Assets > Manage Compentencies".
  2. At the bottom of the new page you'll be presented with a couple of options under the heading of "Additional Programs". In order to sell Office 365 you must enrolled for "Microsoft Online Services Partner Agreement, otherwise known as MOSPA. So click on the "Status" link for that.
  3. Read carefully the agreement and sign up for it if you're happy to proceed. 
  4. Complete the relevant documentation around the tax and banking information. This varies from country to country so please make sure you follow the steps very carefully.
  5. Wait for the response email or notification from Microsoft that you have confirmed your billing information.


Part 2: Registering for Office 365

Get your Office 365 subscription as part of you MPN Action Pack by following the steps at https://support.microsoft.com/en-us/kb/3007588. There is no need for me to repeat the robust instructions on that KB article here! 


Part 3: Resell and offering free trials in Office 365

After completing parts 1 and 2 you're now ready to resell and offer free trials in Office 365! But you're probably thinking how right? You don't see any option in the Office 365 Administrator Portal to complete such function! Well to do this you need to use an account with "Global Administrator" rights on your Office 365 subscription and head to https://portal.office.com/partner/default.aspx. From here you're able to complete the first trials or purchase orders by using the "Build your business" link on the left hand pane.


Also of interest here is the "Request delegate admin permissions" option. This is for the situation where an existing customer of Office 365 may become a new client of your IT consultancy business. So in other words, you're asking to be able to make changes to their existing Office 365 subscription once you've been given the access.


Part 4: Using Microsoft marketing material (optional)

Personally I really like Microsoft's marketing material around Office 365 for Microsoft Partners. Not only is it just easier to use their advertising and not worry about designing it yourself, the adverts are very professional and do give your organisation that edge in my opinion against others who do it on their own and poorly… Telstra in Australia for example really fail to promote Office 365 for what it does and that's one of the biggest problems with people and organisations alike taking it on. If it doesn't make sense they'll stay away from it.

If you're wanting potential customers to leverage your free trial offers but rather don't want to have to send a unique one out each time, you can use the same trial on one advert that is shared. To to this complete the following:

  1. In the Office 365 Partner Portal, create a free trial with the licenses etc. you want to offer.
  2. On the "Send" page copy the URL from the text are and keep it handy. You'll need it later on.
  3. Click Finish to compelte the trial. Once you've done that you're actually finished with the Office 365 Partner portal and can log out it if you wish.
  4. Log into the Microsoft Partner Network again if you have previously logged out.
  5. Head to "Resources > Marketing > Overview".
  6. On the new page, select "Syndicated Marketing".
  7. Because in this situation we're offering free trials of Office 365 to our potential customers, select the "Office 365 with trial option"
  8. Select "Customize".
  9. Complete all the details on the customise page that you need for the invitation URL, copy and paste the URL you grabbed from step 2.
  10. Click "Generate Code". 
  11. With the generated code, use it as you please either in your organisations website, promotional HTML email or any other advertising medium. When uses click on that link and register for the free trial, they'll be using your organisations offering and you'll be able to (if you selected it in step 1) control their subscription with delegated admin rights. Once the trial is over you can speak to the customer and hopefully, if the trial has gone well get them onto Office 365 and secure the deal!

That's it for now. Any questions or queries please don't hesitate to ask!

TOGAF 9 – Quick guide

This is a rare blog post for me as I'm not usually one to reference how-to videos on YouTube but I have recently been watching Craig's videos to really give me a good refresher on the methodology that is TOGAF. I invite others who may be studying towards TOGAF or need a refresher on the methodologies to give these videos a try. Try to make sure you watch all of it through and take notes, especially around the 'Transition Planning' part of the TOGAF ADM cycle. That is where most of the time a IT Solutions Architect or System Engineer will spend his time. 

On a bit of a side note it's funny how many who I talk to today that still feel that TOGAF like ITIL and PRINCE2 are those types of fluffy certifications that no on really leverages. While to some extent this may be true, you never really use 100% of the three practices, it's still very handy to have and deploy in your organisation or as part of a transition in IT infrastrcuture. For example you can thank ITIL for Change Management which is now a very common practice in the IT industry!


Remove disabled users from AD groups

I had an interesting request from a client today in so far they wanted AD to be cleaned out completely… Hrrm? Okay? So what do you mean by cleaned? *Insert joke about dcpromo demoting the domain*. 

The response I got was –  "We want you to delete all the disabled AD accounts".

While I thought okay, that's possible I still had my questions. Why? What are these disabled accounts hurting? Why do they need to vanish off the face of the earth? 

It's an interesting topic to discuss around the industry as I'm personally not one to delete users ever! Though I have worked with others who insist on deleting and even moving disabled AD users in another OU. The latter being simply administrative overhead and something that is easily averted by using an LDAP query that doesn't show them. Plus if another administrator later on enables them again and forgets to move them back to the appropriate OU then that account could be getting the right the right Group Policy settings!

Accounts that have been disabled for well beyond 10+ years I believe still have a place in your AD. Why? Well that person could still one day could return at any time. Why not give them their old account again rather than worry about provision a new one. Sure you can delete their mailbox which is consuming space and maybe delete the contents of their home share (not the actual folder thouht) but that account still belongs to someone… It still has an idenity and a face that needs to be kept for historical and future purporses.

To give you an example, I had another client have the same user leave and return three times in as many weeks! Yike right! Well no problem, I didn't have to go repeating the account provisioning process over and over.

Another reason not to go blowing your accounts away to hell is how indenity management is making massive inroads in our industry. For one example Office 365 with one way provisiong (DirSync or the coming WAAD) use your AD as the authoritive source. When you start deleting accounts you're disjoining those objects in the synchronisation metaverse. Not a problem when you delete, but when a new account with the same old UPN comes back, it can be quite a pain. 

So after a bit of coming and going with the client they finally came back to me with their reasoning…. "I don't like seeing all the disabled members in ADUC/ ADAC when I'm modifying group memberhship."

This particular client allows their in-line managers to manage group memebership for their files shares and some distribution groups. This was possible thanks to some nifty AD delegation I set up for them a few months earlier.

So no worries I now know what they want me to do. They don't want the accounts to dissappear, but they do want them to be isolated from all their old security groups. I supported this request as it's always good practice for any business to review users group memberships and there is no better time to do that then when the new user or a user returns…. "Okay Jimmy, what access do you actually need".

So rather than go around and delete the same 100 account or so from 500 different security groups I got onto PowerShell again. Scripting is seriously good for things like this! 

WARNING: Do not use this script if you has placed all your users and groups so to speak in the original "Users" container (not OU) in a domain. Many Microsoft services etc. can leverage disabled accounts in group membership for delgation etc. and running this script over those groups will pull them out. This script also doesn'y log very well as it justs spits the output to the console… So it will be difficult to go add all the accounts back in, especially if dealing with a lot of users or groups.

Import-Module ActiveDirectory
foreach ($group in (Get-ADObject -Filter { (ObjectClass -eq "group") -and (mailNickname -like "*") } -SearchBase "ou=groups,ou=staff,ou=contoso,dc=contoso,dc=com")) {
  Write-Host $group.Name -Foreground "green";
  foreach ($member in (Get-ADGroupMember -Identity $group)) {
    if ($member.objectClass -eq "user" -and ($member.distinguishedName.ToLower().Contains("ou=users,ou=staff"))) {
      $user = Get-ADUser -Identity $member.distinguishedName
      if ($user.enabled -eq $false) {
        Write-Host $user.Name
        Remove-ADGroupMember -Identity $group -Members $user -Confirm:$false

There are some important aspects of this groups you should take note of. These are:

  1. The –SearchBase parameter is where your AD groups you wish to clean are.
  2. The $member.distinguishedName.ToLower().Contains is where you store your AD users.
  3. The if ($user.enabled -eq $false) is what makes sure the account is Disabled. You could change this if statement for example if you wanted to remove all users with a particular office location, phone number or event last name!

That's it for now, next blog post will be whenever I feel a need to put something up! 

Copy AD groups from one user to another

It seems that a lot of my posts recently have been around AD group membership and I guess that makes sense as for the past few weeks I have been mostly cleaning up a lot of the mistakes by other IT professionals for my new clients. Alas it's coming a long way with PowerShell.

This script is very simple but a goody. It copies the group memberships of one user and gives it to another. 

  [parameter(Position=0, ValueFromPipeline = $true, ValueFromPipelineByPropertyName = $true, mandatory=$true)][string]$SourceUser,
  [parameter(Position=0, ValueFromPipeline = $true, ValueFromPipelineByPropertyName = $true, mandatory=$true)][string]$DestinationUser

Import-Module ActiveDirectory;

$originalErrAction = $ErrorActionPreference;
$ErrorActionPreference = "SilentlyContinue";

$groups = (Get-ADUser -Identity $SourceUser -Properties MemberOf).MemberOf;

foreach ($group in $groups) {
  Add-ADGroupMember -Identity $group -Members $DestinationUser;

$ErrorActionPreference = $originalErrAction;

Save this as Copy-ADGroups.ps1 or something similar and call is by running .\Copy-ADGroups.ps1 $SourceUser $DestinationUser where the $value is replaced with the AD user idenity. E.g. "Trent Steenholdt".

Audit Active Directory quick and dirty. Find all administrators, disabled users and lastlogin (UTC)

I had the need today to do a quick audit of Active Directory and see where it was at for a client. Not just the norm like dcdiag.exe, repadmin and checking the Event Viewer to see if there were any issues but also how many administrators there are, who is disabled (if any as I had my doubts) and the last last login for each user. PowerShell to the rescue. 

if ((Get-Module -Name ActiveDirectory) -eq $nul) { Import-Module ActiveDirectory }

$admins = Get-ADGroupMember -Identity "Administrators" -Recursive
$admins += Get-ADGroupMember -Identity "Domain Admins" -Recursive
$admins += Get-ADGroupMember -Identity "Enterprise Admins" -Recursive

Write-Host "Administrative accounts" -ForegroundColor Green
foreach ($admin in ($admins | Sort-Object -Property sAMAccountName -Unique)) { if ($admin.objectClass -eq "user") {Write-Host $admin.sAMAccountName} }

Write-Host "Disabled users" -ForegroundColor Green
foreach ($user in (Get-ADUser -Filter {Enabled -eq $false} | Sort-Object -Property sAMAccountName)) { Write-Host $user.sAMAccountName }

# I'd STRONGLY recommend using the -SearchBase parameter to reduce query load if at all possible
Write-Host "Last logon times (UTC)" -ForegroundColor Green
foreach ($user in (Get-ADUser -Filter * -Property lastLogonTimestamp | Sort-Object -Property sAMAccountName)) { if ($user.lastLogonTimestamp -eq $null) {$dt = ''} else { $dt = [datetime]$user.lastLogonTimestamp }; Write-Output($user.sAMAccountName +","+ $dt) | Write-Host }