Configuration Management on Servers

Nano Server is a remotely administered headless server operating system optimized for private clouds and datacenters. Nano Server is significantly physically smaller than Server Core, has no local logon capability and only supports 64-bit applications, tools and agents. As we prepare to release Windows Server 2016 Technical Preview 5, I wanted to provide more information on how to properly configure Nano Server at scale – without Group Policy.

One of the things that makes Nano Server so interesting is that it takes up far less disk space, installs significantly faster, and requires far fewer updates and restarts than Windows Server. When it does require a restart, it restarts much faster. To achieve this speed and small physical footprint, Nano Server has the absolute minimum amount of inbox components. As a result, Group Policy and the associated Group Policy Management Console (GPMC), editor (GPMC), Group Policy client and local policy editor (GPEdit) tools are not present on Nano Server. This is expected as they are graphical components and Nano Server is headless and remotely managed. Even when domain joined, Nano Server will not consume and enact Group Policy settings.

So, without Group Policy, how do you apply security policies to Nano Server? We have a series of documents coming out to answer this question. The first one can be found here:

Windows Server 2016 Technical Preview 5 still has complete Group Policy controls, of course. In fact, it has its fair share of new Group Policy Settings, even over Technical Preview 4. You can find the updated Windows 10 / Windows Server 2016 TP5 group policy settings here. Client SKUs also have Group Policy in full.

To sum up:

  • Nano Server has different capabilities than Windows Server 2016
  • Nano Server does not have the Group Policy editing, management, or client service.
  • To manage Nano Server security policy, refer to this post:
  • Windows Server 2016 and Windows 10 clients continue to have full support for Group Policy.


from Group Policy Team Blog

New enhancements to #AzureAD Domain Services

Howdy folks,

Today we’re announcing a cool set of enhancements to Azure AD Domain Services (AAD DS). With > 3500 customers already actively using this new service (while it’s still in preview!), AAD DS has been a unexpected hit. Those customers have given us a lot of helpful feedback and today we’re announcing some new features based on their requests:

  • Secure LDAP access
  • Custom OU support
  • Administer DNS for your managed domain
  • Domain join for Linux VM’s (no, that is not a typo!)

And in case you didn’t see the news when we originally announced it AAD DS is now available in Australia!

Mahesh Unnikrishnan, the Program Manager who leads our AAD DS efforts, has written up some details on these enhancements which you’ll find below.

I hope you’ll find these new capabilities useful. As always, we’d love to receive any feedback or suggestions you have.

Best regards,

Alex Simons (Twitter: Alex_A_Simons)

Director of Program Management

Microsoft Identity Division


Hi there!

I’m Mahesh Unnikrishnan, a Program Manager in the Identity division at Microsoft. Late last year, we announced the public preview of an exciting new service called Azure AD Domain Services. We’ve seen incredible customer demand for this service. The past few months have been a great learning experience for us and we’ve gotten a ton of valuable feedback from our preview customers. We continue to evolve the service and refine it based on this feedback.

Today, I’m thrilled to announce updates to our public preview. We have quite a few new features for you to try out.

Secure LDAP access to your managed domain

Many directory-connected applications use LDAP (Lightweight Directory Access Protocol) to connect to Active Directory, in order to authenticate users or to lookup additional information about the user. Secure LDAP, also known as ‘LDAP over Secure Sockets Layer (SSL)/Transport Layer Security (TLS)’, provides a secure way to do this. Secure LDAP ensures that sensitive LDAP traffic in your domain is not visible to anyone with a network packet analyzer. This level of security is indispensable, if you want to connect to your directory from an external network or over the internet.

We’re excited to deliver support for Secure LDAP in Azure AD Domain Services. You can now connect over secure LDAP from any virtual machine within the virtual network in which you’ve enabled Azure AD Domain Services. You can also configure your managed domain to allow Secure LDAP connections over the internet. This is useful if you need to connect to your directory from another network or from a different location. This cool new functionality enables you to lift-and-shift applications that rely on Secure LDAP from your on-premises infrastructure and deploy them confidently in Azure.

Get started – Configure secure LDAP (LDAPS) for your managed domain

Create and administer custom organizational units (OUs)

Some customers told us they would like to lift-and-shift legacy on-premises line of business applications, which rely on service accounts to authenticate with the directory, to Azure. Some of these service accounts are configured with password policies that differ from those for end-user accounts. An example of this is configuring service account passwords to never expire. Other customers have told us how they would prefer to put sets of their domain-joined computers into different organizational units (eg. all web-servers in a single OU, database servers in a different OU etc.) for ease of administration.

With this nifty new feature, members of the ‘AAD DC Administrators’ group can now create a custom Organizational Unit (OU) on your managed domain. Further, they get full administrative privileges for the custom OU they’ve created and can perform tasks such as creating service accounts within the OU.

Get started – Create an organizational unit on your managed domain

Administer DNS for your managed domain

Many of our Azure Infrastructure Services customers deploy workloads that require them to configure and deploy load-balancers or other non-domain joined virtual machines. They need to configure DNS in order to ensure these machines are reachable from other machines.

Azure Active Directory Domain Services provide DNS resolution for your managed domain within the virtual network in which you’ve enabled the service. Occasionally, it may be necessary to configure DNS on the managed domain in order to create records for machines that are not joined to the domain, create virtual IP addresses for load-balancers or configure external DNS forwarders. Members of the ‘AAD DC Administrators’ group can now administer DNS on the managed domain using DNS administration tools.

Get started – Administer DNS on your managed domain

Domain join Linux virtual machines

We’ve engineered Azure AD Domain Services to make it easy for you to join your Azure Infrastructure Services virtual machines to the managed domain. You can then manage these virtual machines using Group Policy and users can sign-in to the virtual machines using their corporate credentials.

We’ve published a step-by-step guide for joining a Windows virtual machine to your managed domain.

We’ve also collaborated with our friends at Red Hat to show you how to join a Red Hat Enterprise Linux (RHEL 7) virtual machine to your managed domain.

We’re now in Australia!

After launching the public preview, we’ve seen a lot of customer requests to add support for the Australia regions of Azure. We’re excited to announce that Azure AD Domain Services is now available in Azure’s Australia East and Australia Southeast regions.

We’re thrilled about the opportunity to evolve Azure AD Domain Services based on your feedback. We’d love for you to try out the service, especially these new features and share your feedback with us.


Mahesh Unnikrishnan

Principal Program Manager

Microsoft Identity Division

from Active Directory Team Blog

Group Policy Security Compliance with PowerShell

Last year we shipped the Group Policy Compliance Manager (GPCM) product–our enterprise compliance reporting solution for Group Policy. Today we are releasing a new PowerShell module to go along…

The post Group Policy Security Compliance with PowerShell appeared first on SDM Software | Group Policy Management & Administration Tools.

from SDM Software | Group Policy Management & Administration Tools

What you need to know about KB3148812

This update introduces two changes that require additional manual steps in order to complete the installation: those who installed it right away had a bit of a panic because the guidance was not yet published.  We try not to require post-update manual effort whenever possible, and unfortunately in this case it was unavoidable.  This post describes the symptoms you’ll see, details how to resolve them, and then provides some background on this change.


Issue #1: Loss of WSUS admin console

After installing KB3148812 and rebooting your WSUS server, you will notice that your console is no longer available, and that resetting the server node does not fix the issue.

The errors in the log will read something like this:

“The WSUS administration console was unable to connect to the WSUS Server via the remote API… The handshake failed due to an unexpected packet format.SourceSystemStack Trace:

at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)”


To recover your console, run the following in an elevated command prompt (assuming Windows is installed on drive C):

cd C:\Program Files\Update Services\Tools

Wsusutil.exe postinstall /servicing

Then reset the server node or reboot WSUS, and you’re back in business.


Issue #2: Clients cannot scan WSUS

After installing KB3148812 and rebooting, you may find that client scans against WSUS no longer succeed. 

To restore client-server communication, enable HTTP Activation on your WSUS server via the Add Features and Roles Wizard in your Server Manager:

Give it a minute, and then try your scans against WSUS again.  After installing this feature, they should succeed.


Why you need KB3148812

Windows 10 builds are staged in encrypted packages to Windows Update several days prior to the actual go-live date.  This is to ensure that we can release to all regions simultaneously when the time comes.  The Windows 10 client has been able to decrypt these packages since RTM; however, WSUS was not able to do this.  Until now, we have been manually decrypting these packages prior to releasing to the WSUS channel, the process of which is both time consuming and prone to errors.  KB3148812 introduces this functionality to WSUS for Windows Server 2012/R2, such that it can now natively decrypt this content.  Skipping this KB means not being able to distribute the Windows 10 Anniversary Update, or any subsequent feature update, via these platforms.  Note that Windows Server 2016 will have this functionality at RTM.


Why WCF with HTTP activation

ASMX was introduced in .NET 2.0, and is an aging technology at this point.  WCF is generally more capable and flexible than ASMX, and other Microsoft services already use WCF, so it made sense to migrate Microsoft Update (and thus WSUS) to the same.


In closing

This post details the steps required to complete the installation of KB3148812, and covers all known issues that might arise.  Should you hit an issue not listed here after performing the steps above, please reach out to us via Email Blog Author so that we can investigate.

from WSUS Product Team Blog

The Importance of KB2871997 and KB2928120 for Credential Protection

Hello, my name is Paul Bergson and this is my first time writing a blog for AskPFEPlat. I am a platforms PFE in the Premier division of Microsoft. If my name looks familiar, it could be because I spent about 10 years in TechNet’s Directory Service Forum as an MVP and Moderator (pbbergs). I wanted… Read more

from Ask Premier Field Engineering (PFE) Platforms