server

Fix Active Directory broken security inheritance problem

Posted on August 8, 2019 by mo wasay PowerShell Windows

Ran into a situation at a client location where in Active Directory, the security permissions applied to an OU were not getting inherited permissions on to the objects. Basically, security inheritance was broken.This causes a problem when the administrative accounts or groups needing to modify an attribute on the AD object throw errors, or are unable to edit the AD object.

To find out which objects were not getting the inherited permissions run the following :

I ran it on the entire domain to identity potential problem accounts. 🙂

#Replace the -SearchBase value with the OU that contains the problems user(s)
Get-ADUser -SearchBase "DC=mowasay,DC=com" -Filter * -Properties nTSecurityDescriptor | ?{ $_.nTSecurityDescriptor.AreAccessRulesProtected -eq "True"}

1 2	#Replace the -SearchBase value with the OU that contains the problems user(s) Get-ADUser -SearchBase "DC=mowasay,DC=com" -Filter * -Properties nTSecurityDescriptor \| ?{ $_.nTSecurityDescriptor.AreAccessRulesProtected -eq "True"}

To fix the issue:

#Replace the -SearchBase value with the OU that contains the problems user(s)
Get-ADUser -SearchBase "DC=mowasay,DC=com" -Filter * -Properties nTSecurityDescriptor | Where-Object
{ $_.nTSecurityDescriptor.AreAccessRulesProtected -eq "True" } | ForEach-Object {
    $_.ntSecurityDescriptor.SetAccessRuleProtection($false, $true)
    $_ | Set-ADUser -Replace @{ntSecurityDescriptor = $_.ntSecurityDescriptor }
}

#Replace the -SearchBase value with the OU that contains the problems user(s)

Get-ADUser -SearchBase "DC=mowasay,DC=com" -Filter * -Properties nTSecurityDescriptor | Where-Object

{ $_.nTSecurityDescriptor.AreAccessRulesProtected -eq "True" } | ForEach-Object {

$_.ntSecurityDescriptor.SetAccessRuleProtection($false, $true)

$_ | Set-ADUser -Replace @{ntSecurityDescriptor = $_.ntSecurityDescriptor }

}

Reference:

https://docs.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.objectsecurity.areaccessrulesprotected?view=netframework-4.8
https://blogs.msdn.microsoft.com/adpowershell/2009/10/22/viewconfigure-protected-acl-and-fixing-broken-inheritance/

Get All DCs in the Entire Forest

Posted on March 6, 2019 by mo wasay PowerShell Windows

Getting a know a new environment for a new client and I a quickly needed information about all domain controllers in the entire forest.

Wrote a small little script to provide me all the information I needed:

Import-Module ActiveDirectory

function Get-AllDCsInForest{
[CmdletBinding()]
param(
    [string]$ReferenceDomain = $env:USERDOMAIN
)
 
$ForestObj = Get-ADForest -Server $ReferenceDomain
foreach($Domain in $ForestObj.Domains) {
    Get-ADDomainController -Filter * -Server $Domain | select Domain,HostName,Site, IPv4Address, OperatingSystem, OperatingSystemVersion
     
}
 
}

Get-AllDCsInForest| Export-Csv -Path C:\Scripts\AllDcs.txt -NoTypeInformation

Import-Module ActiveDirectory

function Get-AllDCsInForest{

[CmdletBinding()]

param(

[string]$ReferenceDomain = $env:USERDOMAIN

)

$ForestObj = Get-ADForest -Server $ReferenceDomain

foreach($Domain in $ForestObj.Domains) {

Get-ADDomainController -Filter * -Server $Domain | select Domain,HostName,Site, IPv4Address, OperatingSystem, OperatingSystemVersion

}

Get-AllDCsInForest| Export-Csv -Path C:\Scripts\AllDcs.txt -NoTypeInformation

Convert a Dynamic IP to Static

Posted on October 18, 2018 by mo wasay PowerShell

Working on a project where on some servers the DHCP assigned addresses needs to be converted to static. Since there is always more than one…I needed to script it.

Here is a quick way to do it via PowerShell.

#SwitchIPtoStatic.ps1
#Get All the adapters that are on the Server
$adapters = gwmi -cl win32_networkadapterconfiguration | ? {($_.ipaddress) -and $_.dhcpEnabled -eq 'True' }

foreach ($adapter in $adapters) {
    # Get original settings
    $ipAddress = $adapter.IPAddress
    $subnetMask = $adapter.IPSubnet
    $dnsServers = $adapter.DNSServerSearchOrder
    $defaultGateway = $adapter.DefaultIPGateway

    # Set to static and set dns and gateway:
    $adapter.EnableStatic($ipAddress,$subnetMask)
    $adapter.SetDNSServerSearchOrder($dnsServers)
    $adapter.SetGateways($defaultGateway)
}

#SwitchIPtoStatic.ps1

#Get All the adapters that are on the Server

$adapters = gwmi -cl win32_networkadapterconfiguration | ? {($_.ipaddress) -and $_.dhcpEnabled -eq 'True' }

foreach ($adapter in $adapters) {

# Get original settings

$ipAddress = $adapter.IPAddress

$subnetMask = $adapter.IPSubnet

$dnsServers = $adapter.DNSServerSearchOrder

$defaultGateway = $adapter.DefaultIPGateway

# Set to static and set dns and gateway:

$adapter.EnableStatic($ipAddress,$subnetMask)

$adapter.SetDNSServerSearchOrder($dnsServers)

$adapter.SetGateways($defaultGateway)

}

Hope this helps!

Force Replication of all Domain Controllers on all Sites

Posted on September 14, 2018 by mo wasay PowerShell Windows

If you want to replicate all Domain Controllers, then you have to start replication on each of them separately. This may take a while. To save time there is an easier way to force replication on all Domain Controllers of all Active Directory Sites.

Log on to one of your Domain Controllers. Start Windows PowerShell with administrative privileges. Using the Get-ADDomain cmdlet we can get the domain name and the domain partition.

function Replicate-AllDomainControllers {
(Get-ADDomainController -Filter *).Name | Foreach-Object {repadmin /syncall $_ (Get-ADDomain).DistinguishedName /e /A | Out-Null}; Start-Sleep 10; Get-ADReplicationPartnerMetadata -Target "$env:userdnsdomain" -Scope Domain | Select-Object Server, LastReplicationSuccess
}

Replicate-AllDomainControllers

function Replicate-AllDomainControllers {

(Get-ADDomainController -Filter *).Name | Foreach-Object {repadmin /syncall $_ (Get-ADDomain).DistinguishedName /e /A | Out-Null}; Start-Sleep 10; Get-ADReplicationPartnerMetadata -Target "$env:userdnsdomain" -Scope Domain | Select-Object Server, LastReplicationSuccess

}

Replicate-AllDomainControllers

Now depending on the size of your environment the results may take some time to appear. The final output should be something like this:

All of Windows Cipher Suites

Posted on May 15, 2018 by mo wasay Windows

Working on a security project and I needed a reference guide as to what cipher suites are supported on what OS.

So I have documented a list of the default cipher suites and their preferred order for every Windows Server version. These were gathered from fully patched operating systems.

These are the server defaults for reference only. I do not recommend using the default cipher suites or the order listed.

Windows Server 2003

TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA

Windows Server 2008

TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5 TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA

Windows Server 2008 R2

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5

Windows Server 2012

TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA

Windows Server 2012 R2

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5

Windows Server 2016

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA SSL_CK_DES_192_EDE3_CBC_WITH_MD5 SSL_CK_RC4_128_WITH_MD5

ConfigMgr 2012 R2 – WSUS sync fails with HTTP 503 errors

Posted on March 19, 2018 by mo wasay Windows

Ran into this issue with ConfigMgr 2012 R2 where it was unable to synchronize Software Update Point with the WSUS server. A review of the component status messages for the SMS_WSUS_SYNC_MANAGER component on the primary site server reveals errors related to WSUS synchronization which are similar to the following:

Message ID: 6703 WSUS Synchronization failed. Message: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.

Got the following error when trying to open Update Services on the WSUS server

Error: Connection Error An error occurred trying to connect to the WSUS server. This error can happen for a number of reasons. Please contact your network administrator if the problem persists. Click the Reset Server Node to connect to the server again.

In addition to the above, attempts to access the URL for the WSUS Administration website (i.e., http://CMCASSERVER:8530) fails with the error:

HTTP Error 503. The service is unavailable

In this situation, the most likely cause is that the WsusPool Application Pool in IIS is in a stopped state, as shown below.

Also, the Private Memory Limit (KB) for the Application Pool is probably set to the default value of 1843200 KB.

If you encounter this problem, increase the Private Memory Limit to 4GB (4000000 KB) and restart the Application Pool. To increase the Private Memory Limit, select the WsusPool Application Pool and click Advanced Settings under Edit Application Pool. Then set the Private Memory Limit to 4GB (4000000 KB).

After the Application Pool has been restarted, monitor the SMS_WSUS_SYNC_MANAGER component status, wcm.log and wsyncmgr.log for failures. Please note that it may be necessary to increase the Private Memory Limit to 8GB (8000000 KB) or higher depending on the environment.

Now WSUS is back online!

Guide to migrate FRS to DFSR

Posted on June 21, 2017 by mo wasay Office 365

For most users this article only applies if you have Window 2003/ 2003 R2 Domain Controller in your enviornment that you are planning to get rid off. Pretty soon I hope! 😉

SYSVOL is a folder shared by domain controller to hold its logon scripts, group policies and other items related to AD. All the domain controllers in network will replicate the content of SYSVOL folder. The default path for SYSVOL folder is %SystemRoot%\SYSVOL. This folder path can define when you install the active directory.

Windows Server 2003 and 2003 R2 uses File Replication Service (FRS) to replicate SYSVOL folder content to other domain controllers. But Windows server 2008 and later uses Distributed File System (DFS) for the replication. DFS is more efficient than FRS. Since windows server 2003 is going out of support, most people already done or still looking for migrate in to latest versions. However migrating FSMO roles WILL NOT migrate SYSVOL replication from FRS to DFS. Most of the engineers forget about this step when they migrate from windows 2003 to new versions.

For FRS to DFS migration we uses the Dfsrmig.exe utility. More info about it available on https://technet.microsoft.com/en-au/library/dd641227(v=ws.10).aspx

In my environment, I am using windows server 2012 R2 server and I migrated FSMO roles already from a windows server 2003 R2 server.

In order to proceed with the migration forest function level must set to windows server 2008 or later. So if your organization not done this yet first step is to get the forest and domain function level updated.

You can verify if the system uses the FRS using dfsrmig /getglobalstate , To do this

1) Log in to domain controller as Domain admin or Enterprise Admin
2) Launch powershell console and type dfsrmig /getglobalstate. Output explains it’s not initiated DFRS migration yet.

Before move in to the configurations we need to look into stages of the migration.

There are four stable states going along with the four migration phases.

1)    State 0 – Start
2)    State 1 – Prepared
3)    State 2 – Redirected
4)    State 3 – Eliminated

State 0 – Start

With initiating this state, FRS will replicate SYSVOL folder among the domain controllers. It is important to have up to date copy of SYSVOL before begins the migration process to avoid any conflicts.

State 1 – Prepared

In this state while FRS continues replicating SYSVOL folder, DFSR will replicate a copy of SYSVOL folder. It will be located in %SystemRoot%\SYSVOL_DFRS by default. But this SYSVOL will not response for any other domain controller service requests.

State 2 – Redirected

In this state the DFSR copy of SYSVOL starts to response for SYSVOL service requests. FRS will continue the replication of its own SYSVOL copy but will not involve with production SYSVOL replication.

State 3 – Eliminated

In this state, DFS Replication will continue its replication and servicing SYSVOL requests. Windows will delete original SYSVOL folder users by FRS replication and stop the FRS replication.

In order to migrate from FRS to DFSR its must to go from State 1 to State 3. This step cannot be reversed.

Migration Steps:

Prepared State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 1 and press enter

4. Type dfsrmig /getmigrationstate to confirm all domain controllers have reached prepared stat

Redirected State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 2 and press enter

4. Type dfsrmig /getmigrationstate to confirm all domain controllers have reached redirected state

Eliminated State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 3 and press enter

4. Type dfsrmig /getmigrationstate to confirm all domain controllers have reached eliminated state

This completes the migration process and to confirm the SYSVOL share, type net share command and enter.

Also make sure in each domain controller FRS service is stopped and disabled. This should happen automatically, but please verify.

Additional Info:

The steps listed above are pretty straightforward. I’d advise to make sure DFSR binaries are current on all DCs for the respective OS versions, then forge ahead 😊

https://support.microsoft.com/en-us/help/2951262/list-of-currently-available-hotfixes-for-distributed-file-system-dfs-technologies-in-windows-server-2012-and-windows-server-2012-r2 (Note: the article has both 2k12 and 2k12R2 binaries by DFS-N and DFS-R, I’m including just the DFSR below)

DFS replication

Windows Server 2012 R2

Date added	Knowledge Base article	Title	Why we recommend this hotfix	Hotfix type and availability
Aug 05, 2016	3172614	July 2016 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2	This hotfix contains the most current version of Dfsrs.exe for Windows Server 2012 R2.	To apply this update rollup, you must be running Windows Server 2012 R2, April 2014 Update 2919355 and April 2015 Update 3021910.
	NA		This hotfix contains the most current version of Dfsrro.sys for Windows Server 2012 R2.	To install this hotfix, you must have Windows Server 2012 R2 installed.
	NA		This hotfix contains the most current version of Dfsrclus.dll for Windows Server 2012 R2.
August 31, 2014, Install this Hotfix	2996883	DFSR stops replication after an unexpected shutdown in a Windows 8.1 or Windows Server 2012 R2 environment	This hotfix contains the most current versions of Dfsrdiag.exe, Dfsrmig.exe and Dfsrwmiv2.dll for Windows Server 2012.	To apply this hotfix, you must be running Windows Server 2012 R2 and April 2014 Update 2919355.

For any 2008/2008R2 DCs, the parallel article to the 2k12 version above, https://support.microsoft.com/en-us/help/968429/list-of-currently-available-hotfixes-for-distributed-file-system-dfs-technologies-in-windows-server-2008-and-in-windows-server-2008-r2 :

Windows Server 2008 R2

Date added

Knowledge Base article

Title

Why we recommend
this hotfix

Hotfix type and availability

Oct/11/2014

3002288

DFSR service freezes when it calls a method on a Windows-based server

Dfsrs.exe

6.1.7601.22842 or newer

This hotfix contains the most current version of Dfsrs.exe for Windows Server 2008 R2 SP1.

Note: For 2008 R2 (RTM) apply: 2725170

To install this hotfix, you must have Windows Server 2008 R2 Service Pack 1 (SP1) installed.

Jan/21/2012

2663685

Changes that are not replicated to a downstream server are lost on the upstream server after an automatic recovery process occurs in a DFS Replication environment in Windows Server 2008 R2

This hotfix adds the ability to enable or disable automatic recovery of DFSR databases via a registry value in Windows Server 2008 R2. (StopReplicationOnAutoRecovery )

Set regkey for autorecovery…….

On Windows 2012 R2 DFSR Autorecovery is enabled by default

To enable the DFS Replication service to automatically recover databases, modify the following registry key:

HKLM\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery

Notes

· If the value of the StopReplicationOnAutoRecovery registry subkey is set to 1, the DFS Replication automatic recovery is disabled.
When the error condition should occur you may note a DFS Replication warning event 2213 like the following:

Log Name: DFS Replication
Source: DFSR
Event ID: 2213
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: MyDFSRMember.contoso.com
Description:
The DFS Replication service stopped replication on volume F:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.

Additional Information:
Volume: F:
GUID: 4A5BAE4E-c19D-21E1-A4E7-007056B54182

· If the value of the StopReplicationOnAutoRecovery registry subkey is set to 0 or if the StopReplicationOnAutoRecovery registry subkey does not exist, the DFS Replication automatic recovery is enabled.

To install this hotfix, you must have Windows Server 2008 R2 or Windows Server 2008 R2 Service Pack 1 (SP1) installed.

Nov/18/2009

975763

DFS Replication does not use Remote Differential Compression (RDC) when replicating very large files on a computer that is running Windows Server 2008 R2

If you have a version of dfsrs.exe installed that is newer than 975763, you do not have to install this hotfix. However, you must still enable the registry change (RpcContextHandleTimeoutMs) that is specified in 975763 for the new behavior to take effect.

To install this hotfix, you must have Windows Server 2008 R2 installed. This hotfix is available for individual download and is included in Windows Server 2008 R2 Service Pack 1.

May/21/2013

2851868

“0x0000003B” Stop error when you use the DFSR service on a Windows Server 2008 R2-based

This hotfix contains the most current version of Dfsrro.sys for Windows Server 2008 R2 SP1.

Dfsrro.sys

6.1.7601.22335 or newer

To install this hotfix, you must have Windows Server 2008 R2 Service Pack 1 (SP1) installed.

Jan/19/2010

979564

The DFS Replication Management Pack shows alerts for cluster network names that are in the “healthy” status on a Windows Server 2008 R2 failover cluster

This hotfix contains the most current version of Dfsrclus.dll for Windows Server 2008 R2 RTM.

To install this hotfix, you must have Windows Server 2008 R2 installed. This hotfix is available for individual download and is included in Windows Server 2008 R2 Service Pack 1.

Nov/18/2012

2780453

Event ID 4114 and Event ID 4008 are logged in the DFS Replication log in Windows Server 2008 R2

This hotfix contains the most current version of Dfsmgmt.dll for Windows Server 2008 R2 and SP1.

Dfsmgmt.dll

6.1.7601.22167 or newer

To install this hotfix, you must have Windows Server 2008 R2 or Windows Server 2008 R2 Service Pack 1 (SP1) installed.

As a best practice, as there will be a parallel directory, SYSVOL_DFSR , created during the migration process, have the A-V admins ensure exclusions are set per https://support.microsoft.com/en-us/help/822158/virus-scanning-recommendations-for-enterprise-computers-that-are-running-currently-supported-versions-of-windows

Q&A

Q: What are the Domain Controller availability requirements during my migration?

A: There are a couple.

The PDC Emulator must be online any time the DFSRMIG tool is being invoked for a read or write operation. If the PDC Emulator is offline or inaccessible for LDAP, the user of DFSRMIG will receive:

“Unable to connect to the Primary DC’s AD.

Please make sure that the PDC is reachable and try the command later.”

All DCs must remain online until they each complete their state steps. All DCs do not need to be accessible simultaneously. But the global state will never reach the Prepared, Redirected, or Eliminated state until all DCs have been able to complete their individual phases.

The PDC Emulator requirement is because by default, administrators always edit group policy on the PDCE, so in most environments it will have the most up to date knowledge of policy. That and we need to talk to someone unique, so it might as well be him.

It is recommended that a SYSVOL migration not be attempted unless all DCs are online and available. Change control blackouts should be scheduled to prevent modification to DCs that might impact their availability. This will minimize the window of time that the migration will take.

Q: Is there some super-secret way to return to using FRS after reaching the Eliminated phase of DFSR migration?

A: Microsoft does not support returning your domain to using FRS for SYSVOL replication after a completed DFSR migration (except to rebuild the domain). This is why the steps are done in a phased approach with two checkpoints where you can revert back to FRS without any consequences. Once you trigger the ELIMINATED phase to start, there is no going back, period.

Q: When does Robocopy run during the migration and what does it do?

A: The DFSR service uses robocopy at several stages to synchronize SYSVOL directories outside of normal replication when it detects a SYSVOL migration is underway; a set of ‘pre-seeding’ and ‘save the GP admins from themselves’ operations.

When Prepared state (DFSRMIG /SETGLOBALSTATE 1) is invoked, all DC’s robocopy their FRS SYSVOL data locally into the new DFSR content set. This is equivalent to ‘pre-seeding’ data and ensures that minimal file replication occurs to converge the content set. This is triggered by the DFSR service itself when:

AD replication has converged between a DC and the PDCE.
The DFSR service on that DC has polled (this runs every 5 minutes) and picks up the state change from CN=dfsr-LocalSettings
When entering the Redirected state, the PDC Emulator (only) robocopies the local differences of FRS SYSVOL data into the new local DFSR content set, on itself. The other servers receive new data via replication.

If you undo the Redirected state back to Prepared, the reverse happens. The PDC Emulator robocopies its local DFSR content set data into its local FRS content set. FRS replication synchronizes all other servers… eventually. Allow more time for this than entering Redirected, as FRS is not as fast to synchronize as DFSR.

For sharp-eyed readers: we won’t run into any of the old pre-seeding issues (the file hash being changed by robocopy) here because DFSR correctly creates the SYSVOL_DFSR folder ACL, so there are no inheritance issues when the contents are copied in and replicated.

Q: Event 8004 says something about RODC’s. I don’t have any RODC’s. What the frak?

A: The following event is incorrectly written in the DFSR event log(s) on servers that are not Read-only Domain Controllers when setting elimination state using DFSRMIG.EXE:

Log Name: DFS Replication
Source: DFSR
Date: 9/28/2007 11:53:46 AM
Event ID: 8004
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: <WRITABLE DC>
Description:
The NTFRS member object for the Read-only Domain Controller <WRITABLE DC> was deleted successfully.

The text in the event log is completely cosmetic and benign. It is supposed be fixed in a later version of the OS. Just ignore it.

Q: What are all the AD and Registry state values that will be set at a given point in the migration?

A: See below:

=============

Prepared Phase – DFSRMIG /SETGLOBALSTATE 1

DFSRMIG contacts the PDC Emulator directly.
Global objects are created under:

CN=DFSR-GlobalSettings,CN=SYSTEM,DC=<domain>
CN=DOMAIN SYSTEM VOLUME
CN=SYSVOL SHARE
CN=CONTENT
CN=TOPOLOGY

CN=DFSR-GlobalSettings now has msDFSR-Flags attribute set to 0.
As DC’s pick up the globalstate change via AD replication and DFSR service polling, they create and write to registry entry:

HKLMSystemCurrentControlSetServicesDFSRParametersSysvolsMigrating Sysvols
Local State = 4 [REG_DWORD]

The PDC Emulator creates the:

CN=dfsr-LocalSettings,CN=<servername>,DC=<domain>

objects for all DCs and sets this attribute to:

msDFSR-Flags = 80 (if RWDCs).
msDFSR-Flags = 64 (if RODCs – the RODC itself will set it to 80 later).

The DFSR service has now started and created the new local SYSVOL_DFSR structure. Robocopy has made a local copy of the FRS SYSVOL. All AD topology data has been written in to support the content set. Initial sync of the data has started (since robocopy has locally pre-seeded the data this should involve minimal replication data on the network). The registry on all DC’s is:

Local State = 5 [REG_DWORD]

Once initial sync is done on all DCs:

Local State = 1 [DWORD] ‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 16

If DFSRMIG /GETGLOBALSTATE returns that all DCs are prepared, ‘msDFSR-Flags’ on CN=dfsr- GlobalSettings has changed to 16 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with FRS being shared as SYSVOL.

=============

Redirected Phase – DFSRMIG /SETGLOBALSTATE 2

DFSRMIG contacts the PDC Emulator directly.
CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 96 on all DCs and this replicates out through AD.
As DCs pick up the attribute from AD replication, their DFSR service sets:

Local State = 6 [REG_DWORD]

On the PDC Emulator only, robocopy syncs any changes between the FRS and DFSR’s content sets, and this is replicated out through DFSR.
Once SYSVOL data is in sync, SYSVOL content set is set to be the active SYSVOL share on all servers. FRS and DFSR are both still replicating data.
When this is complete, for each DC:

Local State = 2 [DWORD] ‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 32

If DFSRMIG /GETGLOBALSTATE returns that all DCs are redirected, ‘msDFSR-Flags’ on CN=dfsr- GlobalSettings has changed to 32 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with DFSR being shared as SYSVOL.

==============

Eliminated Phase – DFSRMIG /SETGLOBALSTATE 3

DFSRMIG contacts the PDC Emulator directly. At this point it is not possible to undo the changes!
CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 112 on all DCs and this replicates throughout AD.
As DCs pick up the attribute from AD replication, their DFSR service sets:

Local State = 7 [REG_DWORD]

On the PDC, the FRS content set information is removed and this is replicated through AD. As each DC sees this change, their FRS service stops replicating the FRS content set. The FRS service is stopped (and restarted if custom FRS sets still exist on a given server).
When this is complete, for each DC:

Local State = 3 [DWORD] ‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 48

If DFSRMIG /GETGLOBALSTATE returns that all DCs are eliminated, ‘msDFSR-Flags’ on CN=dfsr-GlobalSettings has changed to 48 because all DCs are prepared. All DCs are currently replicating DFSR only.
A final cleanup task on each DC will set their ‘msDFSR-Flags’ on CN=dfsr-LocalSettings to <NOT SET>. The same will happen from the PDC to CN=dfsr-GlobalSettings.

==============

If any ‘undo’ phases are entered (where an administrator has decided to go from redirected back to prepared, redirected back to start, or prepared back to start), the flow above happens in reverse, with the exception that the following two entries exist in the ‘Local State’ registry entries:

(Undo Redirecting)
(Undo Preparing)

Q: I’m not a huge fan of Ultrasound. Are there any other ways to validate the health of SYSVOL prior to and after migration?

A: Sure thing – already discussed in a TechNet blog post here (Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style).

Q: Are there any migration KBs or bugs I need to worry about?

A: One KB, with a simple solution to domains that have non-standard (and frankly, not any safer than default) security configurations: http://support.microsoft.com/kb/2567421 (Manage Audit and Security Logs user rights required)

CAUSE: The default user rights assignment “Manage Auditing and Security Log” (SeSecurityPrivilege) has been removed from the built-in Administrators group. Removal of this user right from Administrators on domain controllers is not supported, and will cause DFSR SYSVOL migration to fail. DFSR migration and must be run by a user who is a member of the built-in Administrators group in that domain. All DCs are automatically members of the built in Administrators group.

Connecting to a remote domain controller using PowerShell

Posted on April 25, 2017 by mo wasay PowerShell Windows

Covering one of the basic day to day task if you are a Windows Administrator; connecting to the domain controller. I try to minimize logging onto servers as much as possible. Your thought should be around connecting to the server remotely and doing the work as needed instead of natively logging on to it.

I will be discussing two approaches below to connect to a domain controller:

Connecting from a client machine on the same domain
Connecting from a client machine on a different domain or a workstation/server

Before we get started, and regardless of which approach you take below, the following will need to be installed on the client Windows machine. Primarily you need to get the Active Directory Module for Windows PowerShell installed.

Installing the Active Directory Module

GUI:

The Active Directory for Windows PowerShell is already built-in into Windows Server operating systems (starting from Windows Server 2008 R2), but it is not enabled by default.

On Windows Server 2016, you can install the AD for PowerShell module from the Server Manager (Add Roles and Features -> Features -> Remote Server Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools -> Active Directory module for Windows PowerShell).

PowerShell:

You can also install the module from the PowerShell console using the command:

Install-WindowsFeature -Name "RSAT-AD-PowerShell" –IncludeAllSubFeature

1	Install-WindowsFeature -Name "RSAT-AD-PowerShell" –IncludeAllSubFeature

The RSAT-AD-PowerShell can be installed not only on the domain controllers, but also on any domain member server or even a workstation. The PowerShell Active Directory Module is installed automatically when you deploying the Active Directory Domain Services (AD DS) role (when promoting server to AD domain controller).

Approach 1: Connecting from a client machine on the same domain

First step you need to do is find all of your domain controllers and allow remote connections to it.

Logon to your one of your domain controllers and open up PowerShell:

winrm quickconfig

1	winrm quickconfig

You need to do this once on each domain controller so you can remotely connect to each one of them at a later time.

You can read more about WinRM here.

Alternatively, the following command can be ran in an elevated Powershell console on the DC. This enables WinRM and configures the firewall so that it can accept incoming commands.

Enable-PSRemoting

1	Enable-PSRemoting

Once that is done you are ready to connect to your domain controller.

Make sure your system is configured to run PowerShell scripts.

#Set the ExecutionPolicy to allow execution of scripts
Set-ExecutionPolicy Unrestricted

1 2	#Set the ExecutionPolicy to allow execution of scripts Set-ExecutionPolicy Unrestricted

Copy the content below and paste it into your PowerShell Editor. Rename your value of “yourdomaincontroller” to your actual DC Server name.

#ConnectAD.ps1
#Connect to your Domain Controller(DC)
#Change the value after the -ComputerName to your know DC

$session = New-PSSession -ComputerName "yourdomaincontroller" -Credential (Get-Credential)
Invoke-Command $session -Scriptblock { Import-Module ActiveDirectory }
Import-PSSession -Session $session -module ActiveDirectory

#ConnectAD.ps1

#Connect to your Domain Controller(DC)

#Change the value after the -ComputerName to your know DC

$session = New-PSSession -ComputerName "yourdomaincontroller" -Credential (Get-Credential)

Invoke-Command $session -Scriptblock { Import-Module ActiveDirectory }

Import-PSSession -Session $session -module ActiveDirectory

Now all command you enter will be applied to the DC.

To check if your connection is successful. Try the command below to get a list of all of your domain controllers.

#Get a list of all domain controllers in your environment
Get-ADDomainController -Filter * | Select-Object name

1 2	#Get a list of all domain controllers in your environment Get-ADDomainController -Filter * \| Select-Object name

Approach 2: Connecting from a client machine on a different domain or a workstation

Windows Remoting works perfectly for same domain situations, and the set-up is relatively straight-forward. It’s extremely powerful when it works, and offers a highly flexible way to securely execute commands remotely.

Problems arise however when trying to use WinRM in mixed domain environments, or where only one machine is on a domain. This requires some additional configuration steps outlined below.

Logon to your one of your domain controllers and open up PowerShell and run the following:

Enable-PSRemoting

1	Enable-PSRemoting

The following registry key needs to be added to the target domain controllers:

New-ItemProperty -name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

1	New-ItemProperty -name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

Make sure the ports are open:

By default, WS-Man and PowerShell remoting use port 5985 and 5986 for connections over HTTP and HTTPS, respectively.

The module is interacting with AD through the Active Directory Web Service that must be installed on your domain controller (communication is performed over the TCP port 9389).

In some environments, you may need to check if the server authentication certs are valid and not expired. Also, in some situations I have seen that if the client is not resolving the FQDN, it is because the DNSzone doesn’t exist in the source domain. Either the zone can be added, or the host file can be modified to add the DC’s FQDN.

Trusted Hosts:

Adding the client IP or name can help avoid errors.

Depending on your environment and what is allowed or not one of the following should work for your situation.

View the computers of TrustedHosts list

To view the list of TrustedHosts added to the machine, type the following command. By default, its value is blank.

Get-Item WSMan:\localhost\Client\TrustedHosts

1	Get-Item WSMan:\localhost\Client\TrustedHosts

Add all computers to the TrustedHosts list

Using the Set-Item cmdlet and the wildcard you can add all the computers to the TrustedHosts list with the following command.

Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

1	Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

Add all domain computers to the TrustedHosts list

In the following command, replace .yourdomain.com with your own domain name.

Set-Item WSMan:\localhost\Client\TrustedHosts *.yourdomain.com

1	Set-Item WSMan:\localhost\Client\TrustedHosts *.yourdomain.com

Add specific computers to the TrustedHosts list

You can add specific computers you choose based on their hostname by separating them with a comma (,) using the following command.

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]

1	Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]

Where ComputerName can be in the Server01 or Server01.yourdomain.com format

Add a computer to an existing list of TrustedHosts

If you have already added some computers to the TrustedHosts list and want to add an additional computer, without deleting the previous entries, you should use the following method. This is because the TrustedHosts list is updated based on the last Set-Item command you have run overwriting the previous entries.

Use the following command to save the current TrustedHosts computer list to a curList variable.

$currentList = (Get-Item WSMan:\localhost\Client\TrustedHosts).value

1	$currentList = (Get-Item WSMan:\localhost\Client\TrustedHosts).value

To add a computer to the current list, type the following command by specifying both the variable you created and the computer name you are going to add.

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$currentList , Server01"

1	Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$currentList , Server01"

Alternatively, to avoid using a variable, add the -Concatenate switch to the Set-Item command to add both new and previous entries. For example:

Set-Item WSMan:\localhost\Client\TrustedHosts -Concatenate -Value Server02

1	Set-Item WSMan:\localhost\Client\TrustedHosts -Concatenate -Value Server02

Add computers to the TrustedHosts list using the IP address

Similarly to the previous commands, you can use an IPv4 or IPv6 address. In the case of IPv6, you have to type the address between [].

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 10.10.10.1,[0:0:0:0:0:0:0:0]

1	Set-Item WSMan:\localhost\Client\TrustedHosts -Value 10.10.10.1,[0:0:0:0:0:0:0:0]

Add computers to the TrustedHosts list using multiple IP address (Most common)

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.10.10.1, 10.10.10.2"

1	Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.10.10.1, 10.10.10.2"

Another way to add trusted hosts is via an elevated Command Prompt:

winrm set winrm/config/client @{TrustedHosts="10.0.2.33"}

1	winrm set winrm/config/client @{TrustedHosts="10.0.2.33"}

Importing the AD Module:

Before using any cmdlets of the Active Directory module, you need to import it to your PowerShell session (on Windows Server 2012 R2/ Windows 8.1 and newer the module is imported automatically).

Import-Module ActiveDirectory

1	Import-Module ActiveDirectory

With this configuration, it’s now possible to authenticate and execute a command remotely with explicit credentials.

Lets check if it is working:

Enter-PSSession -ComputerName 10.0.2.33 -Credential $Credentials

1	Enter-PSSession -ComputerName 10.0.2.33 -Credential $Credentials

It WORKS! 🙂

Common Errors & Solutions:

Error: WinRM service started. Set-WSManQuickConfig : <f:WSManFault…. WinRM firewall exception will not work since one of the network connection types on this machine is set to Public…… Change the network connection type to either Domain or Private and try again.

Solution:

Enable-PSRemoting -SkipNetworkProfileCheck -Force

1	Enable-PSRemoting -SkipNetworkProfileCheck -Force

Explanation:

The above error message indicates that we have set the network to Public in order to enable PowerShell Remoting. Several ways exist to change the connection type. For some reason that only Microsoft knows, you can’t do this in the Network and Sharing Center.

Error: Enter-PSSession : Connecting to remote server 10.0.2.33 failed with the following error message : The WinRM client cannot process the request….

Solution:

winrm set winrm/config/client @{TrustedHosts="10.0.2.33"}

1	winrm set winrm/config/client @{TrustedHosts="10.0.2.33"}

Explanation:

In an Active Directory environment, you can just use the computer name to connect to a remote machine. If you remotely connect to a standalone machine, you usually have to use the IP address instead. If you try to connect to the remote computer with the Enter-PSSession cmdlet using the IP address of the remote machine, PowerShell will throw the above error.

Error: Cannot connect to host…

Solution:

Check with your network/ firewall team if the port 5985, 5986, and 9389 are open.

Explanation:

Most of the times the ports are overlooked and are the root cause as to why the connection is not working

Reset Windows Server 2012 R2 RDS 120 Day Grace Period

Posted on April 12, 2017 by mo wasay Windows

The RD Licensing grace period has expired and the service has not registered with a license server with installed licenses. A RD Licensing server is required for continuous operation. A Remote Desktop Session Host server can operate without a license server for 120 days after initial start up.

The official solution is to Activate the RDS/TS CAL License server and point the Server to License server with User/Device License and will be resolve the problem, but if you want to reset the timer and again avail the 120 days grace time here is the solution:

Delete the REG_BINARY in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod

To delete the key you must take ownership and give admin users full control.

After a restart of the server RDS will reset the grace period to 120 days.

No remote Desktop License Server available on RD Session Host server 2012 R2

Posted on April 12, 2017 by mo wasay Windows

A fully functional and activated 2012 R2 Remote Desktop Session Host server displayed the following message:

This was a simple setup on one server with the: connection broker, Session Host and Licensing server with 2012 R2 CAL’s installed.

Even though the licensing seems to be configured correctly, in server manager:

and PowerShell:

Licensing diagnostics:

everywhere you look, everything seems to be OK. But the license manager shows something odd:

No licenses are being used? This server was used since late 2012. Some interesting things could also be found in the event logs, the following events appear:

EventID: 1130
Source: TerminalServices-RemoteConnectionManager

The Remote Desktop Session Host server does not have a Remote Desktop license server specified. To specify a license server for the Remote Desktop Session Host server, use the Remote Desktop Session Host Configuration tool.

and:

EventID: 1128
Source: TerminalServices-RemoteConnectionManager

The solution was to delete the REG_BINARY in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod

Only leaving the default.

Note: you must take ownership and give admin users full control to be able to delete this key.

After a reboot the server should be working again, licenses are now being used:

Although everything seemed to be OK and configured correctly with valid licenses, it seems that the setup was still in a 180 day grace period, even though it was correctly configured.

server

Fix Active Directory broken security inheritance problem

Get All DCs in the Entire Forest

Convert a Dynamic IP to Static

Force Replication of all Domain Controllers on all Sites

All of Windows Cipher Suites

ConfigMgr 2012 R2 – WSUS sync fails with HTTP 503 errors

Guide to migrate FRS to DFSR

Migration Steps:

Prepared State

Redirected State

Eliminated State

Additional Info:

DFS replication

Windows Server 2012 R2

Windows Server 2008 R2

Q&A

Reset Windows Server 2012 R2 RDS 120 Day Grace Period

No remote Desktop License Server available on RD Session Host server 2012 R2

Categories

Archives

Meta

server

Migration Steps:

Prepared State

Redirected State

Eliminated State

Additional Info:

DFS replication

Windows Server 2012 R2

Windows Server 2008 R2

Q&A

Installing the Active Directory Module

Approach 1: Connecting from a client machine on the same domain

Approach 2: Connecting from a client machine on a different domain or a workstation

Make sure the ports are open:

Trusted Hosts:

View the computers of TrustedHosts list

Add all computers to the TrustedHosts list

Add all domain computers to the TrustedHosts list

Add specific computers to the TrustedHosts list

Add a computer to an existing list of TrustedHosts

Add computers to the TrustedHosts list using the IP address

Add computers to the TrustedHosts list using multiple IP address (Most common)

Importing the AD Module:

Lets check if it is working:

Common Errors & Solutions:

Categories

Archives

Tags

Meta