Category Archives: PowerShell

Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 2 — Post-Config

Previous part — Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 1 — Installation


In this post we will perform two configurations on our Active Directory Domain Services instance: We’ll define security tiers which later become cornerstones of our privilege delegation principles and we’ll tune domain-joining parameters. Also a quick tweak for the DNS service.

Continue reading Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 2 — Post-Config

Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 1 — Installation


Up to this day, Active Directory Domain Services (AD DS) has been the core of the Windows infrastructure. With each release of Windows Server, AD DS receives new features while keeping great backward compatibility. Windows Server 2016 brings following enhancements to AD DS:

In this blog we shall install the corner stone of our future infrastructure: a highly-available AD DS instance of two domain controllers. Our AD DS layout is going to be quite simple: two writable domain controllers in a single site.

Continue reading Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 1 — Installation

Building Highly-Available Windows Infrastructure: Command-line Style

Several months ago Windows Server 2016 was released. With this release Microsoft has made two significant changes in Windows Server installation options:

  • Nano Server was introduced
  • Server with a GUI now includes desktop experience features (it is even called “Server with Desktop Experience”) and there is no supported way to remove them. This should force IT Administrators to deploy Server Core more broadly.

Looks like now is a good time to stop thinking about Windows Server as a GUI based system and pivot your management approach to be more command-line.
This post is the first in a series of how to build your own highly-available Windows infrastructure using just PowerShell and some other command-line tools. I plan to discuss the following components:

  • Active Directory Domain Services,
  • Active Directory Certificate Services,
  • Desired State Configuration,
  • Key Management Services,
  • DHCP,
  • SCDPM,
  • SCCM,
  • Exchange Server,
  • And, possibly, S4B Server, as well.

I am not able to deploy Hyper-V hosts yet, as all my infrastructure is purely virtual and the host machine, sadly, is running Windows Server 2012 R2 and currently it is impossible for me to upgrade it.

All PowerShell code will not use any hardcoded values. Instead, at the beginning of each post, I shall include a set of variables which will allow you to easily recreate the infrastructure in your environment w/o any change in the code.

The first part is already here! Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 1 — Installation

Huge refactoring of Synchronize-DNSZones.ps1

Today I finished huge refactoring of my Synchronize-DNSZones script (see more about it here). The main reason to refactor was to introduce a support to synchronize zone-level records. To efficiently achieve this, I converted a huge pile of code into several smaller functions. I also improved code readability by PS 3.0 standards (apparently, it is also StrictMode-compatible now).
I improved error handling by introducing 3 new error events:
55 – DNS-zone creation is not yet supported. (And I don’t think I’ll ever support it)
72 – Function New-DnsRecord failed.
82 – Cannot import DNSClient PowerShell module.

I finally replaces unapproved verbs in function names to approved ones (see Get-Verb). I shall change the name of the script itself later.
Fixed an issue when Receive-DnsData sometimes returns empty response and.
Fixed typos and incorrect error handling and slightly enhanced comments.
And I also added forgotten definition of $SMTPCc variable.

In the future I plan to add ShouldProcess support (WhatIf).

Pull-requests / issues are welcome!

Split-brain DNS Synchronizer

The latest version of the script available at GitHub.

Many companies use the same domain name for both internal and external servers hosting. When an internal domain name is a name of AD DS domain, and internal users must access some of the servers by their external IP-addresses, the problem arises: somehow all these external names must exist in the internal zone and the record information in these internal records must be in correspondence with the external ones. There are several possible solutions to resolve such situation:

1. Blindly forward all external requests to AD DS controllers. In this case, domain controllers are the primary name servers for the zone.


  • Single point of management.
  • No new software on domain controllers required.


  • You cannot point internal and external users to different hosts for the same DNS-record.
  • Requires to allow external users access to internal servers, which might be impossible due to security policies. Possible exposure of internal infrastructure to an external malicious user.
2. Have two separated set of DNS-servers for internal and external zones.


  • You can point internal and external users to different hosts for the same DNS-record.
  • External users do not access internal servers.
  • No new software on domain controllers required.


  • Two different points of management. DNS-records may become outdated.
3. Use DNS policies – the new Windows Server 2016 functionality.


  • Single point of management.
  • You can point internal and external users to different hosts for the same DNS-record.


  • Requires domain controllers migration to the latest software, which is not possible for some organizations.
  • Requires to allow external users access to internal servers, which might be impossible due to security policies. Possible exposure of internal infrastructure to an external malicious user.


Currently, I prefer the second method, with two sets of DNS servers. But in that case we have another challenge: How to ensure that all DNS-records, which must point to the same location for both external and internal users, are in sync?
Continue reading Split-brain DNS Synchronizer

How to allow users to join their computers into AD domain

Imagine, that half of your company users are local administrators at their machines. They pretty often reinstall operating systems and request IT Service Desk to join that newly installed OSes into corporate Active Directory domain. One usually has two options to help the users: either to come to the user’s workstation and use one’s credentials to join a PC into domain, or to recreate workstation’s computer account, at the same time allowing employee’s user account to join the computer into a domain by him-/herself. In the first case, ServiceDesk employee needs to walk to a user’s desk, which may be quite exhausting, especially for remote locations, in the second case, computer’s group membership will be probably lost and a new account must be added into all appropriate groups manually.
Is it possible to decrease time and effort put into resolution of such requests? Yes, absolutely!

The main trick is to assign a user with following permissions to his computer’s account:

  • Validated write to DNS host name
  • Validated write to service principal name
  • List the children of an object
  • Read
  • Read security information
  • List the object access
  • Control access right
  • Delete an object and all of its children
  • Delete
  • Write to the following properties:
    • sAMAccountName
    • displayName
    • description
    • Logon Information
    • Account Restrictions

User with abovementioned permissions will be able to join their PC into an AD domain without any assistance from Service Desk.

I made this little script to automate the permissions assigning. Please look into the help section (or use Get-Help cmdlet) to find out about its syntax and usage examples.

In case you use Windows 8.1/Server 2012 R2, you might need to install KB 3092002, either way, only member of the “Domain Admins” group will be able to execute the script. This is due to a bug in the Set-Acl cmdlet. The fix for Windows 10 is included in the latest RSAT package.

If you unsure how to use the script or experience any errors, please leave a comment below or contact me directly.

How to simplify SCDPM servers maintenance

Every DPM administrator, ever tried to perform a regular maintenance onto a set of SCDPM servers (monthly updates, for example), knows that the only one way to do it correctly, i.e. without interruption of backup jobs, is to gracefully shutdown the server. To achieve this, you need to disable active SCDPM agents, connected to this server, and wait till every running job will be completed.

The only problem is — there is no quick way to get a list of every computer with an active agent connected to a SCDPM server. One may say, I’m wrong here and there IS a quick way — just use Get-DPMProductionServer cmdlet with “ServerProtectionState -eq ‘HasDatasourcesProtected'” filter. But you forgot about cluster nodes: If we protect clustered resource, but not cluster nodes themselves, we will not see them in an output of Get-DPMProductionServer (with abovementioned filter applied, of course). In addition, the output will contain clustered resources, which are useless in our task to stop every active protection agent.

That’s why I want to present you with a solution to quickly get a list of only real computers with an active SCDPM-agent installed. Just pass names of your SCDPM-servers to it (or don’t pass anything for localhost) and you’ll receive a collection of ProtectedServers in response. You may then pass that collection directly to Enable/Disable-DPMProductionServer cmdlets.

How to limit a number of PowerShell Jobs running simultaneously

Recently, I received a task which required me to run a particular command on a several thousands of servers. Since execution of this command takes some time, it is just logical to run them in a parallel mode. And PowerShell Background Jobs are the first thing comes in mind.
But resources of my PC are limited — it cannot run more than a 100 jobs simultaneously. Unfortunately, PowerShell doesn’t have a built-in functionality for limiting background jobs yet.

Though, I’m not the first one who stuck with the same problem: official “Hey, Scripting Guy!” blog has introduced us a queue based on .NET Framework objects. But I couldn’t manage this solution to work and needed something simpler. After all, all we need are:

  • a loop
  • a counter, for how much jobs are active and running
  • a variable, allowing next job in queue to start

Eventually, I came up with a piece of code like this:

Whereas my version is similar to a solution proposed at StackOverflow (which I only found AFTER completing my own version, of course), the SO version suffers from a bug where some items in queue may be skipped.

While PS Jobs are so easy to play with, Boe Prox claims that runspaces work much and much faster. Go, check it out, how you can use them to accelerate your job queue in his blog.

Some other queueing technics in PowerShell:

SCCM: Device Collection Based On a Local Group Membership

New task came up recently – I need to separate in SCCM self-managed workstations from IT-managed ones. We define following criteria for IT-managed workstations: no other accounts are in local Administrators group except for built-in Administrator, Domain Admins group and a group for Service Desk administrators. All workstations are located in the same OU, so I cannot use OU-based collections.

As you may know, SCCM 2012 doesn’t have built-in tools to get local groups membership. Thanks to Sherry Kissinger who solved this problem for us using Compliance Settings. After you install her package, you’ll get a new Configuration Baseline and Configuration Item in SCCM console named as “WMI Framework For Local Groups with Logging” and “Local Group Members into WMI with Logging”. This package also creates 2 new tables and 1 view into SCCM database: LocalGroupMembers_DATA, LocalGroupMembers_HIST and v_GS_LocalGroupMembers0.

After creating and deploying baseline, you can use v_GS_LocalGroupMembers0 view to create reports based on local groups membership.
Don’t forget: you must not deploy that baseline to domain controllers! For example, you can create a collection which includes all your systems except domain controllers: create new device collection using All Systems as limiting collection and add it with include rule, then add All Domain Controllers collection with exclude rule. You can download MOF-file for such collection here.

Unfortunately, neither LocalGroupMembers_DATA, nor v_GS_LocalGroupMembers0 can be used in WQL-queries when you create a collection.
Am I stuck? Let’s review what do I had for now:

  • I have all data about local groups membership in custom table.
  • I can create any reports using that data.
  • I can create collections using data from standard tables in SCCM DB.
  • But I cannot create collections based on a data from custom SQL-tables.

I need a way to put data from table LocalGroupMembers_DATA into standard SCCM tables and PowerShell is here to save the day.
There are at least two ways to get data from SQL with PowerShell:

  1. Connect to DB directly and use T-SQL queries with SQL cmdlets.
  2. Connect to SQL Server Reporting Services using New-WebServiceProxy cmdlet. Stefan Stranger and Jin Chen wrote an example script to achieve it.

With PowerShell we can do anything with that SQL-data. Our goal is to populate device collections with workstations and here we go again with two different options:

  1. We can add computers into group in AD DS and then create a device collection using this group. For this method to work you need to activate Active Directory Group Discovery discovery method for site and domain where AD group will reside.
  2. Add computers into collection directly using Add-CMDeviceCollectionDirectMembershipRule cmdlet.

Since both group and a report will be useful for me in the future, I’m stick with them.

Now our scenario looks like this:

  1. Activate Active Directory Group Discovery.
  2. Collect local group membership using Compliance Settings.
  3. Create a report with gathered data an any SSRS.
  4. Get names of computers from this report with New-WebServiceProxy cmdlet.
  5. Add these computers into an AD group.
  6. Create a device collection by that AD group.

I build a report where I list all computers don’t comply with conditions discussed earlier.
Here is what first DataSet query looks like:

It can be easily expanded to include another set of groups to ignore.
Mind CompOU parameter: in web-interface you can select multiple OUs where to search computers.
To get a full list of OUs from a forest, you can use another query:

I modified RenderSQLReportFromPosh.v1.000.ps1 so it could populate AD DS group in addition to get data from reports. Here’s its code:

My modified script receives a report from $URL and $ReportPath locations, compares a list from it with members of $GroupName AD DS group and adds/removes computers from that group until it and the report would be the same.
You can find a path for log of actions in $Log variable. Here, script records all computers which were added or removed from the group.
OUs to search are defined into $param1 and $param2 variables. If you need more OUs, create a new parameter variables and do not forget to add them into $parameters.

As last, I created standard device collection based on AD group $GroupName.

You can download report as an RDL-file and a script here. Do not forget to create DataSource in the report to connect to your SSRS instance.