Cleaning up DNS after DC demotion

For many of our clients, this is not a big deal…. however recently i was involved in an AD upgrade for an environment with 100’s of sites… and this environment being…. not well kept… wasn’t surprising that many “old” DC entries did not clean up nicely.

With that in mind, it was time to pull out my terrible powershell skills (and ask one of my guys for help when i got stuck)

This client has a couple of forward of lookup zones, but 100’s of reverse lookup zones…. so in order to ensure the name server was gone from all of these zones i used

Get-DnsServerZone -ComputerName <Name of DNS Server> | where {$_.IsReverseLookupZone -eq “True”} | ForEach-Object {Try {Remove-DnsServerResourceRecord -ZoneName $_.ZoneName -RRType “NS” -RecordData “<name of the old server i wasnt to remove witha . at the end” -Name “@” -force} catch {“$_”}}

For cleaning out the sites i then used

Get-DnsServerResourceRecord -ComputerName <Name of DNS Server> -RRType “SRV” -ZoneName <name of zone> | where {$_.RecordData.Domainname -like ‘*servername*’} | Remove-DnsServerResourceRecord -ZoneName <name of zone> -force

if you want to check (without removing) – or simply verify… run

Get-DnsServerResourceRecord -ComputerName <Name of DNS Server> -RRType “SRV” -ZoneName <name of zone> | where {$_.RecordData.Domainname -like ‘*servername*’}


Exchange migration and AdminSDProp

I recently did a piece of work for a client – moving from Exchange 2010 to 2016. Nothing too exciting…. but they did have an interesting issue.

Once migrating some of test mailboxes, inheritance in AD had to be enabled for a few admin accounts before they could connect via outlook and activesync – to be expected (yes yes, i know admin accounts shouldn’t have mailboxes, but we all know that some clients still do this – and thats not the focus of this post)

What was interesting, was that on further investigation – every account has AdminCount set to “1” and had inheritance disabled – not something to handle manually..

On further investigation, it was found that via some group nesting, all users were members of print operators.

Groups with AdminCount=1 can be located utilising the powershell

Get-ADGroup -LDAPFilter “(admincount=1)”

The client did not want to immediately reverse this due to potential client impacts – and while i disagreed – excluding a group from AdminSDHolder was not something i had looked into before – so i was interested.

A short amount of googling later – and reading a long list of articles, we decided to exclude “print operators” from AdminSDHolder. Two of the better articles (for reference) around this were:

The condensed version of the overall solution is:

  • In order to exclude a group from AdminSDHolder, you can utilise ADSIEdit to modify  the property dsHeuristic under “CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=YourDomain,DC=com”
  • The value can be calculated depending what groups you wish to exclude, the 2nd linked technet social post above has a really nice explanation
  • in my case, i needed to it to “0000000001000004” (without the quotes)
  • Once this is done, clear the AdminCount property from the appropriate group (in my case, this was “print operators” + another group within the long-line of nesting this client had)
  • Re-run the powershell – “Get-ADGroup -LDAPFilter “(admincount=1)” to verify the groups no longer show up
  • Once this is done, we need to remove the “adminCount” from each of the affected user accounts and enable inheritance – to do that, you can run the below script


$users = Get-ADUser -ldapfilter “(objectclass=user)” -searchbase “<DN of path you wish to use for your search base>”
#$users = Get-ADUser -Identity <username> ‘ Use this for testing on a single user first

#Get domain values
$domain = Get-ADDomain
$domainPdc = $domain.PDCEmulator
$domainDn = $domain.DistinguishedName

#HashTable to be used for the reset
$replaceAttributeHashTable = New-Object HashTable

$isProtected = $false ## allows inheritance
$preserveInheritance = $true ## preserve inheritance rules

ForEach($user in $users)
# Binding the users to DS
$ou = [ADSI](“LDAP://” + $user)
$sec = $ou.psbase.objectSecurity

Set-ADUser -identity $user -clear adminCount

if ($sec.get_AreAccessRulesProtected())
#Changes AdminCount back to &lt;not set&gt;
Get-ADuser $user.DistinguishedName -Properties “admincount” | Set-ADUser -Remove $replaceAttributeHashTable -Server $domainPdc
#Change security and commit
$sec.SetAccessRuleProtection($isProtected, $preserveInheritance)




Active Directory 2019 and Exchange 2019 – what’s new

The short answer is – not much.

Exchange 2019 was released a few weeks back, but was effectively un-usable, as Exchange 2019 requires Windows Server 2019…. and Windows server 2019 got pulled from release (like Windows 10 1809) due to some issues.

Windows Server 2019 was re-released a few days ago, which allowed nerds everywhere (including me) to put Server 2019 and Exchange 2019 into a test environment.

The most striking thing that is immediately noticeable is that everything looks the same…. The install process, the GUI, the management, all looks the same as it did in 2016. To me, this is a good thing – while Microsoft of the past seemed to believe that moving functions between areas was good – some consistency is nice to have too.


Active Directory

First appearances indicate there is nothing new in AD 2019, the installation process and management is exactly the same as 2016.

While installing, there is not even an option to set the forest and domain functional level to “2019” – only 2016.

A quick look at the schema version indicates it has increased and quick google finds this article

So, while there is something new in the schema, its an incredibly small update….. and there are no new features or functionality of any type to focus on.


Exchange 2019

Exchange 2019 is a bit the same as AD, everything appears to be the same as Exchange 2016, from the install process to the management interface.

A google comes up with this

Should you upgrade to Exchange Server 2019?

So there are some changes and feature updates – but these updates may not have an impact/matter to your organization.


I found these two releases interesting overall as

  • AD is the core of many enterprise networks
  • Exchange is a core business application

To see a new release of both of these products with very minimal improvements I think demonstrates where all Microsoft’s development effort is going (which, to be fair, we already knew)


Importing AD powershell module into Windows PE and then using encrypted creds

Powershell makes life much easier than vbscript…. however it does have its downsides…  signing policy can sometimes be a bit of pain and the modules you need have to be available…. which is an issue in particular for Windows PE.

Mick (good aussie name there) was nice enough to write a blog on how to import powershell into PE – without having to add it statically to the boot wim –

I was a little lazy here and copied both x86 and x64 required directories via robocopy rather than determining the version via powershell like Mick did.

The next step however is the more important one…. a task sequence doesn’t allow us to run a powershell command in PE with credentials, we need a secure way of running the command. In my case, I want to delete a computer object….

Step 1 – Generate a key file (perform on any full OS)

$KeyFile = “\\sccm\PSource$\OSD.DeleteComputer\DeleteComputer.key

$Key = New-Object Byte[] 16


$Key | out-file $KeyFile


Step 2 – Encrypt a password using the key

$PasswordFile = “\\sccm\PSource$\OSD.DeleteComputer\DeleteComputer.txt

$KeyFile = “\\sccm\PSource$\OSD.DeleteComputer\\DeleteComputer.key

$Key = Get-Content $KeyFile

$Password = “Your password here” | ConvertTo-SecureString -AsPlainText -Force

$Password | ConvertFrom-SecureString -key $Key | Out-File $PasswordFile


Step 3 – Create your script utilising the creds – (Below is the one I use to delete a computer object)

Import-module ActiveDirectory

#SCCM TS Object
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

#SCCM Variables
$CompName = $tsenv.Value(“_SMSTSMachineName”)

# Get current path in order to get encrypted password
$MyDir = [System.IO.Path]::GetDirectoryName($myInvocation.MyCommand.Definition)
$User = “Domain\Account”
$PasswordFile = “$MyDir\DeleteComputer.txt”
$KeyFile = “$MyDir\DeleteComputer.key”
$key = Get-Content $KeyFile
$MyCredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, (Get-Content $PasswordFile | ConvertTo-SecureString -Key $key)

# Remove the computer from AD
Remove-ADComputer -Identity $CompName -server <DC name required> -Credential $MyCredential -confirm:$false


Now before you say it…. yes, this is not very secure. It will stop a random snooper type person from seeing a plain text password…. but it will not stop someone who has 1/2 an idea about pressing F8 to get into the running TS (if you have it enabled) and then grabbing the key and txt and being able to use them…. so use (or don’t use) appropriately for your environment.

Making your software product too hard to obtain….

A client has recently merged and are looking at doing a merging into a single forest/domain structure – but up until that happens, they are keen to get the basics, immediately – such as file, calendar and address book sharing – all of which is fair enough.

It had been a while since I looked at GALsync-type solutions – so I did a bit of a search to find what was current.

One of the solutions I came across was Quest Quick Connect Express for Active Directory via

I’ve never been a huge fan of the quest products – they seem to get sold pretty hard by Dell consultants who don’t care if the product actually meets the needs of the client – and they are fucking expensive, however, when used for the right job – they actually do work pretty well.

In this case, I found the dell download link ( and proceeded to try and obtain this free product. Two account sign ups later – I’m not entitled to the software…. so does that mean its now paid software when it previously free? Fair enough – might be worth mentioning that by having a licensing link on the page, or pricing etc… something to indicate it isn’t free anymore.

Is there a trial available ? Doesn’t look like it.

In short Dell – that fucking sucks. I don’t care that its not free anymore – I care that you made me jump through hoops to find out that it wasn’t free anymore – and also gave me no indication as to what the price is, where I can find out what the price is, what (if any) trial/demo’s are available etc. Absolutely zero useful information.


Group Policy – Disabled SOM – ?

I implemented SCCM 2012 for a client a last week and, as per our usual process, implemented an SCCM client health check script which runs as part of a computer start up script in a group policy object.

Came back after a few days – nothing had updated…. “odd” I thought…. but this client had some APPV clients that were still RTM, not SP1 as required for SCCM 2012 and also had disabled vbscript via an archaic method previously…. but the fixed for them seemed to be working.

After running RSOP (server side) and gpresult (client side) – I was getting “disabled SOM” as the reason my GPO was being denied…. never heard of that one before….

turned out, disabled SOM means “Disabled scope of management” and is commonly caused by using block inheritance in group policy…. as regular readers may know – I hate block inheritance… I think it is generally used poorly.

In this case, I was applying a site based policy – and someone had enable block inheritance at the domain level…. (which i’d never seen before)…. because sites are considered to be “above” the domain…. it meant site-linked policies were blocked.. got rid of the block – all was good.

Anyhoo – I thought that was both an odd and interesting one…. one that i’d never seen before and probably never will again!

Microsoft and management interfaces….

Consistency…. its what we spend a great deal of time fixing for clients…. sure, they see us writing standardisation documents for AD/Exchange/Group Policy/Logon scripts etc….. but really, what we are doing is trying to delivery consistency – simply because the more things that are consistent within an environment, the more logical it is – and the easier it is to support.

Take for example the very simple case of mapped drives….. some clients have the whacky situation where S: is mapped to \server1common for some people and \server7finance for others…. this ofcourse makes the job the the helpdesk much harder – as users dont know (nor should they need to) what a unc is…. they just cant find the file on their S: drive. A consistent naming standard for user accounts, email addresses etc are commonly used by the majority of places we deal with – as it just makes sense.

Anyhoo – onto the point of the post – Microsoft products and their management interfaces.

A while ago, the NT 4 option pack to be exact, MMC was introduced, with talk about MS products standardising on using MMC’s for management…. this kind of took off…. AD tools, computer management, event viewer, services etc etc all were (and still are) available as mmc snap-ins….. very handy for standardised management and also creating your own snap in. Other products such as Exchange, ISA/TMG, OCS and SCCM used an MMC-like management console….

Some of these weren’t necessarily the best….SCCM 2007 was universally panned for its shit interface (but it still did the job)…. OCS 2007 i didnt think was that bad, but the devs apparently did…. and exchange 2010 EMC was fucking awesome (a bit slow… but functionality and layout wise it was great)

On the upside, the SCCM 2012 interface is not an MMC at all, and its awesome… well laid out, relatively easy to find stuff, responsive etc….

The we have Lync 2010 with the silverlight interface…. for some of the admin tasks, but an MMC for the topology tasks and powershell for all taks, but some must be completed via powershell. While i find it usable – and dont mind it, its a bit dis-jointed.

Then we have the slight shift to the side – in powershell. Basically the only was to do all the tasks required in exchange 2007/2010 and Lync was to use powershell…. this was a little annoying for clients, but offered an absolute crapload of scripting power… so it was, on the whole, awesome.

Now, we have the wave 15….. SCCM 2012 interface is awesome…. Lync 2013 interface is the same a 2010…. a bit of a (oddly ok) thrown together mees…. Exchange 2013 has thrown out the awesome 2010 EMC and replaced it with a web interface, which is ok… but not as good as the interface it replaced!

So, whats the point of this article… give us some consistency!

1) Having a powershell interface for products is awesome…. keep doing it – and keep exapnding the number of features it covers. The commandlets however need to keep consistency as well… which so far, has been reasonable (i have a vague memory of a few of the Lync commandlets not quite fitting wtih the get/set/new/remove nomenclature)

2) A web interface for certain admin tasks as an option is fine – but a web interface should never be the primary interface in my opinion…. sure the silverlight ones are slightly less painful – but they still suck compared to a GUI

3) Give us a consistent GUI interface…. i get that the teams internally at MS might not see eye to eye a lot of the time and that the interface has to be right for the product…. but FFS… the reason that the OCS 2007 interface sucked, wasnt because mmc sucks, its because the OCS interface sucked. The SCCM 2012 interface is awesome – and even though its not an MMC, I think that same type of interface would also fit well for exchange/lync/AD etc….

4) i’d be disappointed if MS went all web with every interface, but if they did it for every product – at least it would be consistent!

In short MS – please give us some consistency with your management interfaces across product lines….

August 15th – Win 2012 and Win 8 available for DL

I’ve made the (fair) assumption that server will become available at the same time as the client.

Im not convinced that many people (in the corporate space) actually care about Win 8…. part of that is because Win7 is a bloody good OS…. if Win-7-to-go existed… i think there would be even less interest in Win 8.

Server 2012 is a bit of a different matter…. while many features are a bit ho-hum, Hyper-V replica’s… there is some big cash savings to be made by swapping from VMWare and SRM… so will be interesting to see how that plays out.

Oh – and the rest of the Wave 15 products that have previews – Exchange, Lync and office 2013… well, im also quite “meh” about them too…. dont get me wrong – its not as if they are terrible – but there is just nothing particuarly exciting about any of them.

The exchange 2013 web management interface, after a few days of using it, i no longer dislike…. i fucking hate it…. moving to that after using the very good exchange 2010 management console is a huge step backwards…. i can only assume the manager that made that decision had smoked something or was busy crapping on about how great “the cloud” was to some sales idiot… or both.

With Lync, its cool to have the web client back – outside of that, while there are improvements, im a bit meh….. annoyed at the lack of authenticated sip trunk – still.

Office…. well, its office… i can imagine its hard for those guys to come up with anything new… it would be nice if they worked with the exchange team to achieve true, no impact exchange failovers… (which they well may have, but im not setting up test DAG’s and CAS arrays to find out until RTM)

On the up side, the more i use SCCM 2012 – the more it rocks. Sure, there are still improvements that could be made….. but holy shit it has come a long way since 2007, its so much more usable, responsive and quick compared to 2007. Now theres a team that got their shit together – well done.

Active Directory in Windows 2012 – domain alias ?

So – ive been reading up on the features of Windows 2012, particularly around AD (dont get me wrong, the hyperV stuff looks awesome – but so much of our recent work has been around AD cleanup, migration and re-design, its kind of a focus right now)

The AD changes seem fairly minor, not bad, just minor. So, here is my, never to be heard plea to the AD development team:

Give me a way to present a netbios domain name alias.

So many of our clients have shitty domain names such as domain or local, or have been acquired/changed business names – and for their own reasons (reasons i dont necessarily agree with) want to present a different domain name to users. So much so, that we end up doing domain migrations that actually have no technical benefit for smaller/midsize places and for the larger places, it just gets put in the “too hard” basket.

I’m obviosuly not across all the complexities of implementing something like this, but its something that would address customer requests…. so if it turned up, it would be awesome. UPN suffixes – while a nice idea, i dont think ive run into a place yet that uses UPN’s to sign in.

Keeping along the same lines – forest root domains….. the fucking cancer that they are…. give us a way of collapsing these down into the resource domain instead of having to migrate up into the forest root.

Both of these aren’t going to happen – and i realise this… but these are realistically (now that AD recycle bin has a GUI) the last couple of major features missing from AD that we get asked for frequently.