Introduction

When we talk about control version systems (CVS), the first thing comes to mind is, of course, program code. In the modern world, one cannot be a decent software developer if they do not use Git or TFS or Mercurial or Subversion etc. But this does not mean only developers benefit from the concept of CVS: Adobe provides designers with its own solutions to manage file versions.
What about us, IT administrators? Given the growing popularity of the infrastructure-as-a-code concept, many IT administrators have already adopted some kind of CVS to store scripts and configurations files.

Today I want to talk about version control for group policies. You probably know that group policies are not exactly text files, therefore, traditional CVSes are not the best choice here. That’s why Microsoft came up with its own solution, which allows us to track changes, compare GPO versions and quickly restore the previous ones: Advanced Group Policy Management (AGPM).

Interesting, that it is not just a CVS, but is also a tool to delegate group policies administration with built-in approval management mechanism.
But even if you work in a small team and do not need GPO management delegation, I still encourage you to use AGPM as a version control system.

AGPM is a part of Microsoft Desktop Optimization Pack, which is a free software set available to Microsoft Software Assurance subscribers. Here’s the official documentation where you can learn more about the product.

Introduction

Sorry it took me so long — a lot has happened in the last six months, including moving into another country and changing jobs. Also, as you can see from several previous posts, I got a little bit carried away with PowerShell.
Another thing with which I got carried away is this post: I even had to split it, eventually. That’s why today, I present you not one, but two blogs at once! Find the next one here: Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 4 — AGPM

Up to this point, we were working on our servers interactively, locally. This is considered not the best practice because you consume server resources to support an interactive logon session. Also it might be inconvenient when you manage a fleet of servers.
In this article we will setup remote management administrative stations, which we will use to manage servers in the lab from then on.

Introduction

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.

Introduction

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.

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.

After the presentation, I was asked a couple of questions:Q: Does the GUI tool send the password in plain text over the network?A: No, LDAP connection is encrypted with SASL. But if you are going to access the password attribute in your own scripts/tools, you may accidentally expose the password if you set LDAP_OPT_ENCRYPT = 0 or will use ldap_simple_bind w/o TLS/SSL.

Q: Why do we even need those local accounts? Why not to disable them completely?A: In case a machine has lost its connection to AD (due to network configuration change, for example), you may want to bring it back on line w/o disruptive actions such as reboot, offline password reset etc. In case if you hope that the machine keeps your offline password hash, you may find yourself in a stressful situation, when you find out that it, in fact, does not.

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.

Pros:

Single point of management.

No new software on domain controllers required.

Cons:

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.

Pros:

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

3. Use DNS policies – the new Windows Server 2016 functionality.

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

Cons:

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→

In case you are not aware of the tool itself and the situation which was uncovering around it for the last couple of months, here’s a quick explanation:
This tool is a little GUI helper, useful for almost every AD admin – it quickly shows the replication status of an AD forest. Close to “repadmin”, but easier to use because of the GUI. Microsoft decided to shut down the tool this February and force all its users to migrate to their new cloud monitoring solution Microsoft Operations Management Suite. To achieve this, MS published an “updated” version of the tool which only “enhancement” was a countdown timer which prevented the tool from running after the February 1st.

The mistake MS made was that they didn’t think that the two mentioned tools serve completely different purposes: one use OMS to continuously monitor their IT infrastructure, but this is not the case when you use AD Replication Status Tool — you spin it up when you need to check AD replication right now, instantly: evaluating new Active Directory forest, troubleshooting replication etc. Also, Microsoft often don’t think about internet-disconnected environments — it’s just technically impossible to use Operations Management Suite in such infrastructures. And, for the last, some organizations just don’t want, or couldn’t by law, give their sensitive data to MS, especially via Internet.

All these misunderstandings lead to the creation of this thread on UserVoice where many IT-specialists expressed their anger and explained why OMS cannot replace the on-premise tool in many ways.

Finally, today, our voices has been heard — on-premise tool is back and we all can lean back and relax, but…

They just won’t leave us so easily:

Anyway, I want to thank everyone in the Operational Insights Team for the understanding of the IT-community needs, Ryan Ries for raising this issue and creating the original thread at UserVoice and, of course, all this would not be possible without you — thanks to all sysadmins who raised their voice and voted, argued and explained their needs to the OMS team.