Active Directory Trusts

Published 11/2016
Recompiled 3/2018


AD Trusts have always been confusing to many, such as, which direction does the trust point? I’ve included an easy to understand analogy that uses you and a friend as an example. I hope this helps. Ping me if you have any questions.


Let’s discuss AD trusts. And further in, after we discuss trusts types, we’ll revisit Kerberos authentication across a trust path, which I’ve previously discussed in the following blog and is pertinent in the scope of explaining trusts:

Active Directory Trusts

Active Directory domain to domain communications occur through a trust. An AD DS trust is a secured, authentication communication channel between entities, such as AD DS domains, forests, and UNIX realms. Trusts enable you to grant access to resources to users, groups and computers across entities.

The way a trust works is similar to allowing a trusted entity to access your own resources. It’s a two-step process. The first step is to establish the trust. The second step is to provide permissions.

For example, if users in the domain require access to a shared folder in the domain, and the two domains are not in the same forest, you would establish the trust where trusts, therefore the direction of the arrow would be points to


For an analogy, if you were to give your car keys to a friend to allow him or her to use your car, you are establishing a trust between you and your friend. In this case, you are the trusting friend, or domain, and the friend is the trusted friend, or domain. Once the keys have been provided, then the next step is to allow access to your resource, or car, by providing permissions to use the car. However, this trust is only in one direction, you trust your friend. If you want your friend to trust you, your friend, or the other domain, must be initiated by your friend, or the other domain.

AD DS Trust Types

There are various trust types. The trust that you create must be appropriate for the design. Trusts can be transitive or non-transitive. The one that you choose to create depends on the scenario and requirements. Other trusts types can be created as required, depending on the scenario. The table below shows the various trust types you can create.

Trusts can be created using the New Trust Wizard found in the Active Directory Domains and Trusts console, or using the Netdom command line utility. If you choose to create one of the one-way trust types in both directions, it can be created simultaneously, or separately. If you create it separately, you must re-run the procedure to establish the trust in the other direction.


Trust Type Characteristics Direction Authentication
Parent-Child Transitive Two-way Kerberos V5
Created automatically when a child domain is added.
Tree-Root Transitive Two-way Kerberos V5
Created automatically when a new Tree is added to a forest.
Shortcut Transitive One-way
Kerberos V5
Created Manually.
Used in an AD DS forest to shorten the trust path to improve authentication times.
Forest Transitive One-way
Kerberos V5
Created Manually.
Used to share resources between AD DS forests.
External Non-transitive One-way NTLM Only Created Manually.
Used to access resources in an NT 4.0 domain or a domain in another forest that does not have a forest trust established.
Realm Transitive or non-transitive One-way
Kerberos V5 Only Created Manually.
Used to access resources between a non-Windows Kerberos V5 realm and an AD DS domain.

Trust Flow: Transitive vs. Non-Transitive

Trust communication flow is determined by the direction of the trust. The trust can be a one-way or a two-way trust. And the transitivity determines whether a trust can be extended beyond the two domains with which it was formed. A transitive trust can be used to extend trust relationships with other domains; a non-transitive trust can be used to deny trust relationships with other domains. Authentication requests follow a trust path. The transitivity of the trust will affect the trust path.

Transitive Trust

· trusts

· trusts

· Therefore, trusts

One-way Trust

· Domain A trusts Domain B, but Domain B does not trust Domain A.

· Domain A trusts Domain C, but Domain C does not trust Domain A.

· Therefore, Domain B does not trust Domain C.

o For these two domains to trust each other, you would need a one way trust created between each other.

Automatic Trusts: and Tree-Root Trusts

By default, two-way, transitive trusts are created automatically when a child domain is added or when a domain tree is added. The two default trust types are parent-child trusts and tree-root trusts.

Parent-Child Trust

A transitive, two-way parent-child trust relationship automatically created and establishes a relationship between a parent domain and a child domain whenever a new child domain is created using the AD DS installation process process within a domain tree. They can only exist between two domains in the same tree with the same contiguous namespace. The parent domain is always trusted by the child domain. You cannot manually create a Parent-Child trust.


Tree-Root Trust

A transitive, two-way tree-root trust relationship automatically created and establishes a relationship between the forest root domain and a new tree, when you run the AD DS installation process to add a new tree to the forest. A tree-root trust can only be established between the roots of two trees in the same forest and are always transitive. You cannot manually create a tree-root trust.


Shortcut Trust

Shortcut trusts are manually created, one-way, transitive trusts. They can only exist within a forest. They are created to optimize the authentication process shortening the trust path. The trust path is the series of domain trust relationships that the authentication process must traverse between two domains in a forest that are not directly trusted by each other. Shortcut trusts shorten the trust path.


Forest Trust

Forest trusts are manually created, one-way transitive, or two-way transitive trusts that allow you to provide access to resources between multiple forests. Forest trusts uses both Kerberos v5 and NTLM authentication across forests where users can use their Universal Principal Name (UPN) or their Pre-Windows 2000 method (domainName\username). Kerberos v5 is attempted first, and if that fails, it will then try NTLM.


Forest trusts require DNS resolution to be established between forests, however to support NTLM failback, you must also provide NetBIOS name resolution support between the forests.

Forest trusts also provide SID filtering enforcement in Windows Server 2003 and newer. This ensures that any misuse of the SID history attribute on security principals (including the inetOrgPerson attribute) in the trusted forest cannot pose a threat to the integrity of the trusting forest.

Forest trusts cannot be extended to other forests, such as if Forest 1 trusts Forest 2, and another forest trust is created between Forest 2 and Forest 3, Forest 1 does not have an implied trust. If a trust is required, one must be manually created.

External Trust

An external trust is a one-way, non-transitive trust that is manually created to establish a trust relationship between AD DS domains that are in different forests, or between an AD DS domain and Windows NT 4.0 domain. External trusts allow you to provide users access to resources in a domain outside of the forest that is not already trusted by a Forest trust.


SID filter quarantining is enabled by default with Windows Server 2003 and newer AD DS domains. SID filtering verifies that incoming authentication requests made from security principals in the trusted domain contain only SIDs of security principals from the trusted domain.

External trusts are NTLM based, meaning users must authenticate using the Pre-Windows 2000 logon method (domain\username).NTLM requires NetBIOS name resolution support for functionality.

Additional reading on creating External Trusts and DNS Support:

Realm Trust

A Realm trust can be established to provide resource access and cross-platform inter-operability between an AD DS domain and non-Windows Kerberos v5 Realm.

  • A Realm trust only uses Kerberos V5 authentication. NTLM is not used.
  • When the direction of the trust is from a non-Windows Kerberos Realm to an AD DS domain (Realm trusts AD DS domain), the non-Windows realm trusts all security principals in the AD DS domain.
  • Realm trusts are one-way by default, but you can create a trust in the other direction to allow two-way access.
  • Because non-Windows Kerberos tickets do not contain all the information AD DS requires, the AD DS domain only uses the account to which the proxy account (the non-Windows principal) is mapped to evaluate access requests and authorization. With Realm trusts, all AD DS domain proxy accounts can be used in an AD DS group in ACLs to control access for non-Windows accounts.


Additional reading:

Trusted Domain Object (TDO)

To understand cross domain authentication, we must first understand Trusted Domain Objects (TDOs). Each domain within a forest is represented by a TDO that is stored in the System container within its domain. The information in the TDO varies depending on whether the TDO was created by a domain trust or by a forest trust.

When a domain trust is created, attributes such as the DNS domain name, domain SID, trust type, trust transitivity, and the reciprocal domain name are represented in the TDO.

When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and then stores the information in a TDO. The trusted namespaces and attributes that are stored in the TDO include domain tree names, child domain names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are stored in each domain, then replicated to the global catalog.

Therefore, because trusts are stored in Active Directory in the global catalog as TDOs, all domains in a forest have knowledge of the trust relationships that are in place throughout the forest. If there are two or more forests that are joined together through forest trusts, the forest root domains in each forest know of the trust relationships throughout all of the domains in the trusted forests.

The only exception to the rule is External trusts to a Windows NT 4.0 domain do not create TDOs in Active Directory because it is NTLM based, in which SPN and domain SIDs do not exist, therefore do not apply.

Additional reading:

Trust Path between Domains

The trust path is the series of domain trust relationships that the authentication process must traverse between two domains in a forest that are not directly trusted by each other.

Before authentication for a user, computer or service can occur across trusts, Windows must determine if the domain being requested has a trust relationship with the requesting account’s logon domain. This is determined by quering the global catalog for TDO data. The Windows security system’s Netlgon service through an authenticated RPC (Remote Procedure Call) to the remote domain’s trusted domain authority, (the remote domain controller), computes a trust path between the domain controller for the server that receives the request and a domain controller in the domain of the requesting account.

The Windows security system extends a secured channel to other Active Directory domains through interdomain trust relationships. This secured channel is used to obtain and verify security information, including security identifiers (SIDs) for users and groups. The trust path is stored for authentication requests to the trusted domain.

Kerberos authentication Sequence between Domains in a Forest


A user in the domains needs to gain access to a file share on a server called domain. This is assuming the User has already logged on to a workstation using credentials from the domain. As part of the logon process, the authenticating domain controller issues the User a ticket-granting ticket (TGT). This ticket is required for User1 to be authenticated to resources.

The User attempts to access a shared resource on \\\share.

The following Kerberos V5 authentication process occurs:

1. The User’s workstation asks for a session ticket for the FileServer server in by contacting the Kerberos Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the service principal name (SPN).

2. The KDC in the user’s domain ( does not find the SPN for in its domain database and queries the GC to see if any domains in the forest contain this SPN.

a. The GC checks its database about all forest trusts that exist in its forest. If a trust to the target domain is found, it compares the name suffixes listed in the forest trust trusted domain objects (TDOs) to the suffix of the target SPN to find a match.

b. Once a match is found, the global catalog sends the requested information as a referral back to the KDC in

3. The KDC in the then issues the workstation a TGT for the domain. This is known as a referral ticket.

4. The workstation then contacts the KDC in the tree root domain to request a referral to the KDC in the

5. The KDC in the domain recognizes the user’s request to establish a session with a resource that exists in a foreign domain’s server.

a. The KDC then issues a TGT for the KDC in the domain.

6. The workstation then presents the TGT for the domain to the KDC in the domain.

7. The KDC queries a GC to see if any domains in the forest contain this SPN. The GC checks its database about all forest trusts that exist in its forest. If a trust to the target domain is found, it compares the name suffixes listed in the forest trust trusted domain objects (TDOs) to the suffix of the target SPN to find a match.

a. Once a match is found, the global catalog sends the requested information as a referral back to the KDC in

8. The KDC issues a TGT for the domain.

9. The workstation then contacts the KDC of the domain and presents the referral ticket it received from its own KDC.

a. The referral ticket is encrypted with the interdomain key that is decrypted by the foreign domain’s TGS.

b. Note: When there is a trust established between two domains, an interdomain key based on the trust password becomes available for authenticating KDC functions, therefore it’s used to encrypt and decrypt tickets.

10. The workstation also presents the KDC in the the TGT it received from the KDC in for the domain and is issued a ST (Session Ticket) for the domain.

a. The ST is populated with the domain local group memberships from the domain.

11. The user presents the ST to the server to gain access to resources on the server in

12. The server, compares the SIDs include in the session ticket to the ACEs on the requested resource to determine if the user is authorized to access the resource. If there is, the user is permitted to access the resource based on the ACL permissions.

Kerberos Authentication with a Shortcut Trust

If a shortcut trust exists from the domain to the domain, then the trust path will shortened, therefore the user authentication path will be direct between the two domains.


Additional Reading


Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services


clip_image0023 clip_image0043 clip_image0063 clip_image0083 clip_image0103 clip_image0123 clip_image0143 clip_image0163


Complete List of Technical Blogs:

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

Fine-Grained Password Policies User Interface in Windows 2012 R2 and Newer


Ace again! Let’s talk about FGPP!

When Active Directory was first introduced in Windows Server 2000, you can only create one password policy for the domain. That was configured in the Default Domain Policy. If you attempted to create a GPO linked to an OU with password policy settings, the Active Directory CSEs (Client Side Extensions – the client side DLLs that determine, download and run GPOs assigned to the computer or user) will ignore them.

FGGP Expanded Requirements

Therefore if an IT infrastructure design required a different password for different locations or users, the only option was to either create a password filter or create a separate child domain or a new Tree in the forest. Of course this came with design challenges, additional hardware and administrative overhead. For a number of years, this was a limitation that IT administrators had no real solution or alternative.

To provide a solution, Fine-Grained Password Policies (FGPPPs), were introduced in Windows Server 2008, continued in Windows 2008 R2. They provided administrators to create a Password Settings Policy (PSO) for a set of user accounts or groups and cannot be linked to GPOs, and the only way to create and administer PSOs and FGGPs are using low-level utilities, such as ADSI Edit.

Windows Server 2012 introduced a new GUI to ease creation and administration of PSOs and FGPPs. In this section, we will learn about the new FGPP and PSO features, and how to create administer them.

  • Why would we need an FGGP?
  • Understanding Password Settings Objects (PSOs)
  • What’s new in Windows 2012 FGGP?
  • PSO Resultant Set of Policies (RSOP)
  • What’s required to implement FGGPs? PowerShell and FGGPs

Why would we need a FGGP?

You can use fine-grained password policies to specify specific password policies in a single domain by applying different restrictions settings for password and account lockout policies to different sets of users and groups in a domain.

For example, you can apply stricter settings to privileged accounts such as administrator accounts, or executive accounts, and apply less strict settings to the accounts of other users. You can also create special password policies for accounts that get their passwords synchronized with other data sources or applications.

Understanding Password Settings Objects (PSOs)

Password Settings Objects (PSOs) have identical password settings as the password policy in a GPO. These settings include password length, complexity, account lockout, password minimum and maximum age, password history settings, PSO link, and Precedence.

PSOs are not linked to an OU. PSOs are applied users or groups. To help keep track of PSOs to an OU, for example, administrators can create an Active Directory group in an OU that is identically named as the group name.

With Windows Server 2008 and Windows Server 2008 R2, ADSI Edit (Active Directory Services Editor), a low level editor, is required to create, modify and apply PSOs to users or groups. ADSI Edit is akin to a “registry editor” that allows you to modify data in the various partitions in the AD database. Using ADSI Edit requires additional knowledge and skill level by an administrator to understand the various Active Directory database partitions and how to access them.

What’s new in Windows Server 2012 FGGPs?

In Windows Server 2012, creating and managing fine-grained password policy can now be performed using a user interface, the ADAC (Active Directory Administration Center), vastly improving ease of administration.

Administrators can now visually see a specific user’s resultant set of policies (RSOP), view and sort all password policies within a given domain, and manage individual password policies.


PSO Resultant Set of Policies (RSOP)

If a user or group has multiple PSOs linked to them, possibly because they are part of multiple Active Directory groups that have different PSOs, only one PSO can be applied. Therefore, the RSOP must be evaluated to insure the correct PSO is applied.

To determine and calculate the RSOP, each PSO has an additional attribute called the msDS-PasswordSettingsPrecedence.

The msDS-PasswordSettingsPrecedence attribute has an integer value of 1 or greater. The lower the value, the higher precedence it has. In a scenario where an AD group has two PSOs linked, with one of them having a value of 2, and the a value of 4, then the PSO with a value of 2 wins, and is applied to the AD group.

RSOP msDS-PasswordSettingsPrecedence Logic:

• A PSO that is linked directly to the user object is the resultant PSO. (Multiple PSOs should not be directly linked to users.)

• If no PSO is linked directly to the user object, the global security group memberships of the user, and all PSOs that are applicable to the user based on those global group memberships, are compared. The PSO with the lowest precedence value is the resultant PSO.

• If no PSO is obtained from conditions (1) and (2), the Default Domain Policy is applied.

Additional reading on RSOP:

AD DS: Fine-Grained Password Policies

What’s required to implement FGGPs?

To point out, Fine-grained password policies can only be applied to global security groups and user objects (or inetOrgPerson objects, a specific attribute some third party applications may use, if they are used instead of user objects).

Requirements include:

  • Only members of the Domain Admins group can set fine-grained password policies, however, the tasks can be delegated to other users.
  • The domain functional level must be Windows Server 2008 or higher.
  • You must use the Windows Server 2012 version of ADAC (Active Directory Administrative Center) to administer fine-grained password policies through a graphical user interface.

Server Manager can be used to install the RSAT tools (Remote Server Administration Tools) on Windows Server 2012 computers to use the correct version of Active Directory Administrative Center to manage Recycle Bin through a user interface.

  • You can use RSAT on Windows® 8 computers to use the correct version of Active Directory Administrative Center to manage FGGPs.

PowerShell and FGGPs

PowerShell can also be used to create and manage FGGPs. For example, the command below will create the following settings:

  • • PSO Name: TestPswd
  • • Complexity: Enabled
  • • Lockout Duration: 30 Minutes
  • • Lockout Observation Windows: 30 Minutes
  • • Lockout Threshold: 0 Minutes
  • • MaxPasswordAge: 42 Days
  • • Minimum Password Age: 1 Day
  • • MinPasswordLength: 7 characters
  • • PasswordHistoryCount: 24 passwords remembered that you can’t use
  • • ProtectedFromAccidentalDeletion: Yes (prevents accidental deletion)
  • • Security Principal Applied to: AD Group called “group1”
New-ADFineGrainedPasswordPolicy TestPswd -ComplexityEnabled:$true -LockoutDuration:"00:30:00" -LockoutObservationWindow:"00:30:00" -LockoutThreshold:"0" -MaxPasswordAge:"42.00:00:00" -MinPasswordAge:"1.00:00:00" -MinPasswordLength:"7" -PasswordHistoryCount:"24" -Precedence:"1" -ReversibleEncryptionEnabled:$false -ProtectedFromAccidentalDeletion:$true
Add-ADFineGrainedPasswordPolicySubject TestPswd -Subjects group1
Additional Reading:

AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

Introduction to Active Directory Administrative Center Enhancements (Level 100)

Creating fine grained password policies through GUI Windows server 2012 “Server 8 beta”
Microsoft Technet, by Tamer Sherif Mahmoud, Team Blog of MCS



Stay tuned for more on Azure and Cloud Computing

Published 10/15/2016

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

clip_image0023[2][2][2] clip_image0043[2][2][2] clip_image0063[2][2][2] clip_image0083[2][2][2] clip_image0103[2][2][2] clip_image0123[2][2][2] clip_image0143[2][2][2] clip_image0163[2][2][2]

Complete List of Technical Blogs:

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

What is Cloud Computing?


Ace here again. This is part of my blog series on Azure and Cloud Computing

This is a short discussion about cloud computing, another aspect of Internet service providers offering to help companies reduce costs by practically eliminating hardware.

Service Providers and Services

In the past few years, many online service providers have gained momentum offering datacenter services to allow customers the ability to host services, applications, and operating systems. These service providers provide 24/7 availability and uptime monitoring, backups, disaster recovery, maintain application updates and provide full support.

As long as an employee has internet access, whether at the office or away, they can access these services and applications.

A Cloud Operating System does what a traditional operating system does – manage applications and hardware, but at the scope and scale of cloud computing, meaning the applications and hardware are operated and managed outside of a company’s network.

The foundations of the Cloud OS are Windows Server 2012 and Windows Azure, complemented by the full feature set of Microsoft technology solutions, such as SQL Server, System Center, Exchange Server, and Visual Studio. Together, these technologies provide a consistent platform for infrastructure, applications and data that can span your datacenter, service provider datacenters, and the Microsoft public cloud.

Public Clouds

Shared Public Cloud

A Shared Public Cloud provides the benefit of rapid implementation, massive scalability, and low cost of entry because multiple tenants share and absorb the overall costs reducing individual tenant costs.

It is delivered in a shared physical infrastructure where the architecture, customization, and degree of security are designed and managed by the hosting provider according to market-driven specifications.

Public clouds have weaker security due to their shared nature.

Dedicated Private Clouds

Dedicated Private clouds are similar to a Shared Public Cloud, except they are delivered on a dedicated physical infrastructure dedicated to a single organization.

Security, performance, and sometimes customization are better in the Dedicated Public Cloud than in the Shared Public Cloud. Its architecture and service levels are defined by the provider and the cost may be higher than that of the Shared Public Cloud.

Private Cloud

Dedicated Private clouds may be hosted by the organization itself at a co-location service where the organization owns all hardware and software, and provide their own full maintenance procedures including disaster recovery solutions, with the co-location only providing 24/7 power and internet connectivity guarantees, or they may be hosted by a cloud services provider, which provides all hardware and software and ensures that the cloud services are not shared with any other organization.

Private clouds are more than just large-scale hypervisor installation. They can use the Microsoft System Center 2012 management suite, which makes it possible to provide self-service delivery of services and applications.

Self-hosted Private Cloud

A Self-hosted Private Cloud provides the benefit of architectural and operational control utilizing the existing investment in people and equipment, and provides a dedicated on-premise environment that is internally designed, hosted, and managed.

Hosted Private Cloud

A Hosted Private Cloud is a dedicated environment that is internally designed, externally hosted, and externally managed. It blends the benefits of controlling the service and architectural design with the benefits of datacenter outsourcing.

Private Cloud Appliance

A Private Cloud Appliance is a dedicated environment that is purchased from a vendor and designed by that vendor, and are based on provider & market driven features and architectural control. They can be hosted internally or externally, and can be internally or externally managed. A Private Cloud Appliance benefits consumers by combining advantages of a predefined functional architecture, lower deployment risk with the benefits of internal security and control.

What does Windows 2012 R2 and Cloud OS Mean to Organizations?

It means organization can shift to efficiently manage datacenter resources as a whole, including networking, storage and computing. Organizations will be able to deliver and manage powerful apps that boost employee productivity providing faster access across private, hybrid (mixture of private & public clouds) and public clouds.

With Windows Server 2012 and newer, and System Center, an organization owns its own private cloud, and they can provide users a self-service portal to request their own multitier applications including web servers, database servers, and storage components.

Windows Server 2012 and the components of the System Center 2012 suite can be configured so service requests can be processed automatically, without requiring manual deployment of virtual machines and database server software.

Microsoft Private Cloud Fast Track

Microsoft Private Cloud Fast Track is a joint effort between Microsoft and its hardware partners to deliver pre-configured solutions that reduce the complexity and risk of implementing a private cloud, and provides and delivers flexibility and choice across a range of hardware vendor options technologies in pre-configured solutions.

For more information on Microsoft Private Cloud Fast Track, and the implementation deployment guide:

Microsoft Private Cloud Fast Track Information New and Improved, by Thomas W Shinder, MSFT, 7/27/2012

For a complete list of Reference Architecture for Private Cloud Documents:

Reference Architecture for Private Cloud



Stay tuned for more on Azure and Cloud Computing

Published 10/15/2016

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

clip_image0023[2][2] clip_image0043[2][2] clip_image0063[2][2] clip_image0083[2][2] clip_image0103[2][2] clip_image0123[2][2] clip_image0143[2][2] clip_image0163[2][2]

Complete List of Technical Blogs:

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

Remote Server Administration for Windows 2012 R2




Ace here again. This discusses remote administration. Simple, right? Maybe not!

Remote Server Administration for Windows 2012 R2

Server Manager in Windows Server® 2012 R2 can be used to perform various management tasks on remote servers. By default, remote management is enabled on Windows Server 2012 R2.You can add remote servers to the Server Manager Server pool in Windows Server 2012 R2 Server Manager.


Discuss the following remote admin methods

  • What is Remote Management?
  • How to Enable and Disable Remote Management
  • Remote Management and Tools Commands
  • Server Manager
  • WinRM
  • PowerShell Remoting
  • Remote Desktop
  • Remote Server Administration Tools (RSAT)

What is Remote Management?

Windows Server 2012 R2 provides the ability to remotely manage multiple servers with a number of methods. One of the newest features in Windows Server 2012 is the ability to use Server Manager for this task.

In addition to Windows Remote Management, you can also use Remote Shell and Remote Windows PowerShell to manage remote computers. This provides you the ability to locally load Windows PowerShell modules, such as Server Manager, and execute PowerShell cmdlets available in the loaded module on remote servers. This allows you the ability to run PowerShell commands and scripts. This works including when the script is only on the local server

Windows Remote Management (WinRM) is the Windows implementation of WS-Management, which is an industry standard, Web-based services based protocol. Windows runs the WinRM as a service under the same name, WinRM. WinRM provides secure local and remote communications for management applications and scripts.

In addition, Windows Remote Management is one of the components of the Windows Hardware Management features to allow secure local and remote Windows Server management across a firewall using standard Web service-based protocols.

If the server hardware has an optional, built-in Baseboard Management Controller (BMC) provided by the hardware vendor, you can also remotely manage a system even if the Windows operating system has not yet booted or has failed. This also allows access to the server’s BIOS.

A BMC is an option m provided by hardware vendors, that consists of a microcontroller and an independent network connection that you can communicate to if the server ever becomes offline.

When a server is not connected to a BMC, WinRM can still be used to connect to WMI remotely in situations where firewalls may block DCOM communications, because WinRM uses the secure web-based port, TCP 443.

Additional Reading on WinRM:

About Windows Remote Management

Hardware Management Introduction (includes BMC information)

How to Enable and Disable Remote Management

There are a number of methods to administer WinRM.

· Winrm.cmd – Command line tool that allows administrators to configure WinRM, get data, or manage resources. For syntax, you can run winrm /? for online help.

· Win-RM Scripting API – Allows you to create remote administration scripts that expose the WS-Management APIs and protocols.

· Winrs.exe –A command line tool to execute CMD commands on remote servers using WS-Management APIs. For example, to remotely get an ipconfig /all from a remote machine, you can run:
winrs – “ipconfig /all”;tasklist

You can also use the help command to see all possible options and syntax:
winrs –?

· IPMI and WMI Providers – The IPMI provider and drivers allow remote hardware management using BMC. These can be used programmatically.

· WMI Service – Using the WMI plug-in, WMI runs together with WinRM to provide data or control functions for remote management.

· WS-Management protocol – SOAP based protocol using XML messages. It is a web-based, firewall friendly protocol running across secure TCP 443 providing industry-standard interoperability to transfer and exchange management information.

Remote Management Tools and Commands

There are a number of ways to enable, disable and configure Remote Management.

Server Manager

To enable or disable Remote Management, in Server Manager Local Server node, click the text next to Remote Management icon.

WinRM Command

You can use the WinRM command to enable, disable, and configure Remote Management.

The syntax is:


You can use the following to check the current Remote Management configuration and status:
winrm get winrm/config

Or you can run it remotely on another server using the WinRS command:
winrs – “winrm /config”;tasklist

To enable or disable Remote Management:
WinMR qc

When the WinRM qc command is run, it performs a number of steps to enable and configure the Remote Management service:

  1. Configures and changes the WinRM service from Manual to Automatic startup.
  2. Starts the WinRM service.
  3. Creates and configures a listener that will accept WinRM requests on any IP address.
  4. Creates a Windows Firewall exception for WS-Management traffic for the HTTP protocol.

If the Windows Firewall is disabled, you will see one of the following error messages:

  • WSManFault
  • Message
  • ProviderFault
  • WSManFault
  • Message = Unable to check the status of the firewall.
  • Error number: -2147023143 0x800706D9
  • There are no more endpoints available from the endpoint mapper.

To view the command syntax and options, you can run winrm -?

WinRM supports the following commands:

  • PUT
  • GET
WinRM Examples:

Start a service on a remote machine:
winrm invoke startservice wmicimv2/Win32_Service?name=w32time -r:DC12

Reboot a remote machine:
winrm invoke reboot wmicimv2/Win32_OperatingSystem -r:FS1

Additional Reading on the WinRM commands:

An Introduction to WinRM Basics – From the EPS Windows Server Performance Team


PowerShell Remoting

There a number of cmdlets that use WMI for remote administration. The cmdlets invoke a temporary connection the remote computer using WMI, runs the command, then closes the session.

These cmdlets do not use WS-Management based remoting, therefore the computer does not require to be configured for WS-Management nor does it have to meet the system requirement for WS-Management. Because they are not WS-Management service related, you can use the ComputerName parameter in any of these cmdlets

You can run the Invoke-Command cmdlets to run commands on other computers.

For example, to get a list of all services on a remote computer that are either running or stopped, you can run the following command
Invoke-Command –computername DC12 –scriptblock {get-service)

Or to see the status of a single service:
Invoke-Command –computername DC12 –scriptblock {get-service WinRm)

Additional Reading on Remote PowerShell:

Windows PowerShell Remoting – Complete list of commands



Remote Server Administration Tools (RSAT) for Windows

Remote Server Administration Tools for Windows®  includes Server Manager, Microsoft Management Console (MMC) snap-ins, consoles, Windows PowerShell® cmdlets and providers, and some command-line tools for managing roles and features that run on Windows Server 2012 R2.



For Server Core, you can use the SCONFIG command and choosing Option #4, then choosing Option #1 to Enable Remote Management, or Option #2 to Disable Remote Management.


Additional Reading on WinRM tools

About Windows Remote Management


Remote Desktop

Remote Desktop has been used for a number of years, and it is the most common method to remotely administer a remote machine. To use Remote Desktop, it must be enabled first on the remote computer. To enable Remote Desktop on the full version of Windows Server 2012, perform the following steps”

  1. Open Server Manager
  2. Click the Local Server Node
  3. Click the “Disabled” status next to Remote Desktop.
  4. The System Properties page appears and is focused on the Remote tab.
  5. Under the Remote tab, select one of the following:
  1. Don’t allow connections to this computer – Default disabled.
  2. Allow connections only from Computers running:
  1. Checkbox: Allow Remote Desktop with Network Level Authentication – If you check this box, this setting enables and only allows secure connections from Remote Desktop clients that support network-level authentication.


You can also enable Remote Desktop on Sever Core using the SCONFIG command.



Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

clip_image0023 clip_image0043 clip_image0063 clip_image0083 clip_image0103 clip_image0123 clip_image0143 clip_image0163

Complete List of Technical Blogs:

This posting is provided AS-IS with no warranties or guarantees and confers no rights.