Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Windows Server’ Category

(2019-10-14) Testing TCP Ports Through Your Firewall

Posted by Jorge on 2019-10-14


You need to test one or multiple ports through your firewall?

Then have a look at the following script, which has “built-in” templates for scenarios using specific TCP ports. You can use pre-defined template names, single port, multiple ports, range of ports. If you want you can add your own templates! Be careful with large ranges! Unfortunately, only TCP Ports are supported and UDP ports are not supported in this script.

image

Figure 1: Sample Output For Single Port

image

Figure 2: Sample Output For Multiple Ports

image

Figure 3: Sample Output For Multiple Ports And Port Range

image

image

Figure 4: Sample Output For Pre-Defined Template

Ohhh, and I almost forgot! You can download the script from here!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Firewall, PowerShell, Tooling/Scripting, Windows Client, Windows Server | Leave a Comment »

(2019-10-12) Gradually Or Specifically Configuring Your Windows Machines For Hybrid Azure AD Join

Posted by Jorge on 2019-10-12


If you have read this blog post, at some point you will need to create a Service Connection Point (SCP), so that your clients know where to find the Azure AD Tenant those clients should register in. In that blog post, and that was the only possibility since the beginning, you create the SCP in the configuration partition of the AD forest.

If your AD forest had to be serviced by just a single Azure AD tenant, you were good to go. If not, you would have a problem.

If you wanted to have all your Windows clients register at at once in the Azure AD tenant you were good to go. If you wanted to deploy in a phased manner, you would have a problem!

Therefore if you need to deploy different Hybrid Azure AD Join settings to your Windows clients, and/or you need to deploy in a phased manner, you can provide the SCP settings in a GPO to configure the required REGISTRY settings.

Clear the SCP from AD

Use the Active Directory Services Interfaces Editor (ADSI Edit) to modify the SCP objects in AD.

  1. Launch the ADSI Edit desktop application from and administrative workstation or a domain controller as an Enterprise Administrator.
  2. Connect to the Configuration Naming Context of your domain.
  3. Browse to CN=Configuration,DC=contoso,DC=com > CN=Services > CN=Device Registration Configuration
  4. Right click on the leaf object under CN=Device Registration Configuration and select Properties
    1. Select keywords from the Attribute Editor window and click Edit
    2. Select the values of azureADId and azureADName (one at a time) and click Remove
  5. Close ADSI Edit

Configure client-side registry setting for SCP

Use the following example to create a Group Policy Object (GPO) to deploy a registry setting configuring an SCP entry in the registry of your devices.

  1. Open a Group Policy Management console and create a new Group Policy Object in your domain.
    1. Provide your newly created GPO a name (for example, ClientSideSCP).
  2. Edit the GPO and locate the following path: Computer Configuration > Preferences > Windows Settings > Registry
  3. Right-click on the Registry and select New > Registry Item
    1. On the General tab, configure the following
      1. Action: Update
      2. Hive: HKEY_LOCAL_MACHINE
      3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
      4. Value name: TenantId
      5. Value type: REG_SZ
      6. Value data: The GUID or Directory ID of your Azure AD instance (This value can be found in the Azure portal > Azure Active Directory > Properties > Directory ID)
    2. Click OK
  4. Right-click on the Registry and select New > Registry Item
    1. On the General tab, configure the following
      1. Action: Update
      2. Hive: HKEY_LOCAL_MACHINE
      3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
      4. Value name: TenantName
      5. Value type: REG_SZ
      6. Value data: Your verified domain name if you are using federated environment such as AD FS. Your verified domain name or your onmicrosoft.com domain name for example, contoso.onmicrosoft.com if you are using managed environment (in case of PHS or PTA as the primary Auth)
    2. Click OK
  5. Close the editor for the newly created GPO
  6. Link the newly created GPO to the desired OU containing domain-joined computers that belong to your controlled rollout population

PS: if you are using ADFS, that same GPO must ALSO target the ADFS Servers!

More information: Controlled validation of hybrid Azure AD join

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), ADSIEDIT, Azure AD Join, Windows Azure Active Directory, Windows Client, Windows Server | Leave a Comment »

(2019-10-08) Synched Computers/Devices Being Cleaned Up From Azure AD

Posted by Jorge on 2019-10-08


Starting with version 1.4.18.0 and higher of Azure AD Connect, you may see some or all of their Windows devices disappear from Azure AD after upgrade to that version and executing a sync cycle. This is not a cause for concern, as these device identities are not used by Azure AD during conditional access authorization. This change won’t delete any Windows devices that were correctly registered with Azure AD for Hybrid Azure AD Join.

If you see the deletion of device objects in Azure AD exceeding the Export Deletion Threshold, it is advised that the customer allow the deletions to go through. How To: allow deletes to flow when they exceed the deletion threshold

Nevertheless you may want to analyze the deletion first. You can read the following blog post to see how you could do that: (2019-10-06) Examining Pending Export Deletions In Azure AD Connect

More information about this can be found through Understanding Azure AD Connect 1.4.xx.x and device disappearance

To verify which devices in your AD are candidates to be deleted in Azure AD, you can use the following PowerShell script: Export Hybrid Azure AD join computer certificates report

This script generates a report about certificates stored in Active Directory Computer objects, specifically, certificates issued by the Hybrid Azure AD join feature. It checks the certificates present in the UserCertificate property of a Computer object in AD and, for each non-expired certificate present, validates if the certificate was issued for the Hybrid Azure AD join feature (i.e. Subject Name matches CN={ObjectGUID}). Before, Azure AD Connect would synchronize to Azure AD any Computer that contained at least one valid certificate but starting on Azure AD Connect version 1.4, the synchronization engine can identify Hybrid Azure AD join certificates and will ‘cloudfilter’ the computer object from synchronizing to Azure AD unless there’s a valid Hybrid Azure AD join certificate. Azure AD Devices that were already synchronized to AD but do not have a valid Hybrid Azure AD join certificate will be deleted by the sync engine as these will be filtered from being synched to Azure AD (CloudFiltered=TRUE).

Now this script works great! But….unfortunately it does not work correctly with an AD forest where you may have multiple AD domains. Besides that, there is a cosmetic issue. So, let’s start with the easy part!

The script allows you to specify the distinguished name of a single object or the distinguished name of an OU. However, if you want to query the complete AD domain instead of just a single OU, you may think that’s not possible. Nope, that’s still possible. The original writer of the script chose to name the variable “DN” for just a single object (computer) and “OU” when query for computers in an OU. This last one may mislead due to its chosen name. Nevertheless, instead of the DN of an OU, you can also specify the DN of a container or the DN of a domain.

In a single AD domain environment, this will work flawlessly. However, in a multiple AD domain environment it may not. Due to historic reasons many companies may still have AD forests with multiple AD domains for which it is not cost effective to consolidate. For example, if you have the AD forest COMPANY.COM, with the following AD domains: COMPANY.COM, CHILD1.COMPANY.COM and CHILD2.COMPANY.COM. If you are COMPANY.COM and you need to query for objects in CHILD1.COMPANY.COM through PowerShell while not specifying the server variable (as in this script), it will throw an error due to a so called redirection. To query for an object from another AD domain you need to also target a DC from that same AD domain. If you need to query multiple AD domains you will be dancing all over the place! Sometimes, there is no other way, but in this case there is! And what if you want to query the complete AD forest while having multiple AD domains? You can always query every individual AD domain, but wouldn’t it be nice to just perform a single AD query that targets the complete AD forest? That is also possible!

When querying AD, especially when having an AD forest with multiple AD domains you always need to think about: (1) is all the data in my LDAP filter in the global catalog or not?, and (2) is the data that I’m looking for in the global catalog?

Then you need to ask yourself: “where to start searching?”. The closer to the objects you want, the better!

Rest assured! All domains objects are in the global catalog! The question is: “which attribute values of those objects are also replicated to the global catalog?”

Any attribute that has the property “isMemberOfPartialAttributeSet” set to “TRUE” also replicates its value(s) to all global catalogs in the AD forest. To find all the attributes in the AD schema for which its value(s) replicate to the global catalog, you can have a look at the following blog post (2015-01-05) Finding Attributes Marked As Members Of Partial Attribute Set (PAS). It has examples with ADFIND, PowerShell and ADSI.

Now looking at this script, the attribute of interest is “userCertificate”.

To see if an attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=<LDAP DisplayName>))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

To see if the “userCertificate” attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=userCertificate))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

image

Figure 1: Partial Schema Info Of The “userCertificate” Attribute

Or you could visit https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac, which will show you

image

Figure 2: AD Schema Definition Of The “userCertificate” Attribute

Guess what?! It does replicate to the global catalog! So, in this case the answer to both questions above is “YES”, therefore we can use the global catalog to perform this query

When you need to query the AD forest, you could start searching in the forest root AD domain and hopefully the client you are using supports Referral Chasing. If it does not, it may throw an error telling you it does not support it, or it just does not do anything. Wouldn’t it be nice to have something represent the AD forest? well, there is something like that, which is called a Phantom Root and it is specified by just 2 quotes and you can only use it when querying against the Global Catalog!

Now for all this to work, some adjustments are needed in the original script! I’ll guide you through that to get a new working script.

First things first. Download the PowerShell script: Export Hybrid Azure AD join computer certificates report 

Replace…

.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -OU ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose

…with

.EXAMPLE
    Looking at a specific computer

   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
    Looking at computer objects within a specific OU
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD domain
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘DC=child,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD forest
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN PhantomRoot -Filename "MyHybridAzureADjoinReport.csv" -Verbose

Replace…

Param
(
    # Computer DistinguishedName
    [Parameter(ParameterSetName=’SingleObject’,
               Mandatory=$true,
                ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # AD OrganizationalUnit
    [Parameter(ParameterSetName=’MultipleObjects’,
               Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $OU,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename

)

…with

Param
(
    # DistinguishedName of computer, OU, or domain
    [Parameter(Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename
)

Replace…

# Read AD object(s)
If ($PSCmdlet.ParameterSetName -eq ‘SingleObject’)
{
    $directoryObjs = @(Get-ADObject $DN -Properties UserCertificate)
     Write-Verbose "Starting report for a single object ‘$DN’"
}
Else
{
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $OU -Properties UserCertificate
    Write-Verbose "Starting report for $($directoryObjs.Count) computer objects in OU ‘$OU’"
}

…with

# Retrieve Object Type Of DN
If ($DN -ne "PhantomRoot")
{
    $objectType = (Get-ADObject -LDAPFilter "(distinguishedname=$DN)").objectClass # Do not use Get-ADObject $DN as it will throw an error if the object does not exist (even with ErrorAction defined)!
}
Else
{
    $objectType = "forestDNS" # Madeup, not for real!
    $DN = ""
}

   
# Read AD object(s)
If ($objectType -eq "computer")
{
    $domainFQDN = $($DN.SubString($DN.IndexOf(",DC=") + 1)).Replace(",DC=",".").Replace("DC=","")
    $directoryObjs = @(Get-ADObject $DN -Properties userCertificate -Server $domainFQDN)
}
ElseIf ($objectType -eq "domainDNS" -Or $objectType -eq "organizationalUnit" -Or $objectType -eq "container" -Or $objectType -eq "forestDNS")
{
    $gcFQDN = $(Get-ADDomainController -Discover -Service GlobalCatalog).HostName[0]
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $DN -Properties userCertificate -Server $gcFQDN`:3268
}
Else{
    Write-Host "Specified DN ‘$DN’" -Foregroundcolor Red
    Write-Host "Incorrect object type of specified DN or DN does not exist!" -Foregroundcolor Red
    Write-Host "Aborting Script…" -Foregroundcolor Red
   
    EXIT
}

UPDATE 2019-10-12: or get the updated version of the script from here

Hopefully this works for you in your AD environment!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Users And Computers, AD Queries, Azure AD Connect, Azure AD Join, Conditional Access, Windows Azure Active Directory, Windows Client, Windows Server | Leave a Comment »

(2018-10-22) Cloning Windows 10 Or Windows Server 2016 May Break Hybrid Azure AD Domain Join

Posted by Jorge on 2018-10-22


When cloning Windows computers you are basically copying everything from some source computer to one or more target computers. One of the benefits is the speed in deployment and the time you same to have to configure stuff every single time. Are there downsides? Yes, there are, at least if you do not take some risk mitigating measures. One of those is the SID of the local computer. Every time you deploy a cloned version of Windows you MUST execute SYSPREP to make the clone gets its own unique SID. If you don’t at the beginning and along the way things may appear to be correct. However, at some point in time you may find yourself with a huge headache trying to understand why something does not work or shows weird behavior.

Recently I found another downside of cloning, that in the end can be mitigated with some post-deployment actions.

For more info about Hybrid Azure AD Domain Join (HAADJ) please also have a look at

I was trying to Hybrid Azure AD Domain Join (HAADJ) a AD domain joined Windows Server 2016 by logging on and waiting for the scheduled task to kick in and checking the correct Event Logs, and later on under the context of “NT AUTHORITY\SYSTEM” by running DSREGCMD.EXE /DEBUG. When running that last command I kept seeing the following error at the end:

DsrDeviceAutoJoinFederated failed with -2146893802
wmain: failed with error code 0x80090016.

After some troubleshooting I discovered that Windows was a cloned deployment. One of the thing that is also cloned is the key material. The key material is in the folder “C:\ProgramData\Microsoft\Crypto\Keys” to “C:\ProgramData\Microsoft\Crypto\Keys”. The solution therefore is to get rid of the old key material and start fresh from the beginning. You can do that by running the following PowerShell commands:

# Rename The “Keys” Folder To “KeysOLD”

Rename-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -NewName "KeysOLD"

# Create A New “Keys” Folder

New-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -ItemType Directory

# Copy The ACL From The “KeysOLD” Folder To The New “Keys” Folder

Get-Acl -Path "C:\ProgramData\Microsoft\Crypto\KeysOLD" | Set-Acl -Path "C:\ProgramData\Microsoft\Crypto\Keys"

Now retry HAADJ by rebooting the Windows computers and logging on, or executing DSREGCMD.EXE /DEBUG under the context of  “NT AUTHORITY\SYSTEM”. It should work now!

REMARK: If you did not know it yet, you can get into the context of “NT AUTHORITY\SYSTEM” by using PSEXEC and running the following command: PSEXEC –i –s CMD.EXE

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Join, Windows Azure Active Directory, Windows Client, Windows Server | 3 Comments »

(2018-10-21) Grant, Revoke Or Get DCOM Permissions Using PowerShell

Posted by Jorge on 2018-10-21


Have you ever needed to script granting or revoking DCOM Permissins, or maybe just retrieving DCOM Permissions? If the answer is “Yes”, then look no further! It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around DCOM Permissions on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

The PowerShell Module to manage DCOM Permissions can be downloaded from here.

Benefits:

  • No dependency on external files
  • Can change permissions on DCOM objects where Administrator doesn’t have access
  • Does not remove callback permissions (Using the Component Services GUI often does)
  • Doesn’t write temporary files during operation
  • Pure PowerShell implementation
  • Fully documented and self contained
  • No code hidden in DLL files or other compiled libraries; fully transparent

Requirements:

  • PowerShell 4.0
  • Elevated administrative rights on local computer
  • Tested on Windows 10, Server 2012 R2, Server 2016

Available Cmdlets:

  • Get-DCOMPermission
  • Grant-DCOMPermission
  • Revoke-DCOMPermission 

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Windows Client, Windows Server | Leave a Comment »

(2018-10-20) Grant, Revoke Or Query For User Rights (Privileges) Using PowerShell

Posted by Jorge on 2018-10-20


Have you ever needed to script granting or revoking user rights, or maybe just querying for user rights? If the answer is “Yes”, most likely you have had to use NTRIGHTS from the good old Windows Server 2003 Resource Kit or do some funky magic around SECEDIT. It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around user rights locally and remotely on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

The PowerShell Module to manage user rights can be downloaded from here.

Benefits:

  • No dependency on external files
  • Can modify any user right; is not limited to "Logon as a Service"
  • Can add/remove rights from the current process token
  • Doesn’t write temporary files during operation
  • Fully pipeline-able
  • Pure PowerShell implementation
  • Supports changing user rights on remote machines
  • Fully documented and self contained
  • No code hidden in DLL files or other compiled libraries; fully transparent

Requirements:

  • PowerShell 3.0
  • Administrative rights on target computer, or elevation on local computer
  • Tested on Windows 10, Server 2012 R2, Server 2016, Server Core 1709

Available Cmdlets:

  • Grant-UserRight
  • Revoke-UserRight
  • Get-UserRightsGrantedToAccount
  • Get-AccountsWithUserRight
  • Grant-TokenPrivilege
  • Revoke-TokenPrivilege

 

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in User Rights, User Rights, Windows Client, Windows Server | Leave a Comment »

(2016-10-14) Windows Server 2016 Now Available On MSDN

Posted by Jorge on 2016-10-14


Microsoft released Windows Server 2016 about three weeks ago. Read about it here.

Yesterday Microsoft also made the Windows Server 2016 ISOs available on MSDN. Use this link to get to those ISOs. You do need to have an account for MSDN and you need to eligible to be able to download the ISOs.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Windows Server | Leave a Comment »

(2016-09-26) Windows Server 2016 Has Been Released

Posted by Jorge on 2016-09-26


Microsoft has released Windows Server 2016!

An evaluation version of Windows Server 2016 is available through Microsoft downloads. Somewhere in October, Windows Server 2016 will be generally available (GA).

Read more about it:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Updates, Windows Server | 1 Comment »

(2015-10-15) Remote PowerShell To Servers Fails

Posted by Jorge on 2015-10-15


Imagine you want to achieve something on a list of servers, and for that you want to use remote PowerShell. Good idea! Smile

Let’s say you have some list of servers in an array, and all servers are specified with their NetBIOS name. For every server you would like to retrieve its Windows version and build number (or of course something else). You could use the following PowerShell script:

$allExistingRWDCs = @("R1FSRWDC1","R1FSRWDC2") $allExistingRWDCs | %{ $rwdc = $_ $rwdcRemotePoSHSession = New-PSSession -ComputerName $rwdc Invoke-Command -Session $rwdcRemotePoSHSession -ScriptBlock { Param( $rwdc = $rwdc ) $windowsVersion = (Get-WmiObject Win32_OperatingSystem).Version $windowsBuildNumber = (Get-WmiObject Win32_OperatingSystem).BuildNumber Write-Host "" Write-Host "Host Name................: $rwdc" -ForeGroundColor Yellow Write-Host "Windows Version..........: $windowsVersion" -ForeGroundColor Yellow Write-Host "Windows Build Number.....: $windowsBuildNumber" -ForeGroundColor Yellow } -Args $rwdc Remove-PSSession $rwdcRemotePoSHSession Write-Host "" }

You copy the script into a PowerShell command prompt window, and….., life is good!

image

Figure 1: Remote PowerShell By Using NetBIOS Style Server Names – Success

I always prefer to use FQDNs instead of NetBIOS style hostnames, therefore I adjust my script accordingly as shown below

$allExistingRWDCs = @("R1FSRWDC1.IAMTEC.NET","R1FSRWDC2.IAMTEC.NET") $allExistingRWDCs | %{ $rwdc = $_ $rwdcRemotePoSHSession = New-PSSession -ComputerName $rwdc Invoke-Command -Session $rwdcRemotePoSHSession -ScriptBlock { Param( $rwdc = $rwdc ) $windowsVersion = (Get-WmiObject Win32_OperatingSystem).Version $windowsBuildNumber = (Get-WmiObject Win32_OperatingSystem).BuildNumber Write-Host "" Write-Host "Host Name................: $rwdc" -ForeGroundColor Yellow Write-Host "Windows Version..........: $windowsVersion" -ForeGroundColor Yellow Write-Host "Windows Build Number.....: $windowsBuildNumber" -ForeGroundColor Yellow } -Args $rwdc Remove-PSSession $rwdcRemotePoSHSession Write-Host "" }

You copy the script into a PowerShell command prompt window, and….., life is suddenly not that good!

image

Figure 2: Remote PowerShell By Using FQDN Style Server Names – Failure

REMARK: depending on the situation you may see other errors messages, like for example “Access Denied”

What the heck! You try to troubleshoot this one, and it may appear to be a tough nut to crack! Although this error message may give you a hint in which direction you should look at, but in my personal case I got the “Access Denied” error. In summary, remote PowerShell while using NetBIOS names was successful and it failed while using FQDNs. At first I started to check the WinRM settings. Again, in my case there was nothing that gave me a hint what could be wrong, until I started to do some network traces, and that’s when I understand what could be wrong. In the network trace I saw, when using FQDNs, that the proxy server was being accessed. Now why the heck is remote PowerShell trying to access the server through the Proxy Server?

With this blog post, I want to save you a long period of swearing and hair pulling.

When you have configured System Wide Proxy Settings , Remote PowerShell will use its configuration accordingly. In my case, the configuration was similar to:

image

Figure 3: System Wide Proxy Settings – Proxy Server FQDN, Port and Bypass List

  • Proxy Server FQDN = GATEWAY.IAMTEC.NET
  • Proxy Server Port = 3128
  • Do not use the proxy server for the following addresses that are also available internally:
    • *.IAMTEC.NL <== FQDN of the internet domain, that’s also available internally (split DNS)
    • <Local> <== Definition for locally used names

With <local>, I first thought that would support both FQDNs and NetBIOS names. WRONG!!!

As mentioned in MS-KBQ262981, “<local>” only covers NetBIOS name style addresses, and NOT FQDNs. Therefore, any FQDN needs to be explicitly specified or be covered by some wildcard FQDN.

So, what was the solution in my case?

Answer: Add the wildcard FQDN that covers my internal AD forest. Therefore “*.IAMTEC.NET” should be added to the bypass list!

Using the following command, I was able to reconfigure the System Wide Proxy Settings:

NETSH WINHTTP SET PROXY PROXY-SERVER="GATEWAY.IAMTEC.NET:3128" BYPASS-LIST="*.iamtec.net;*.iamtec.nl;<local>"

REMARK: when configuring the System Wide Proxy Settings, services that leverage those settings may exist that need to be restarted to consume the new configuration. One of those examples is ADFS. However, this does not apply to Remote PowerShell.

image

Figure 4: Setting Proxy Server FQDN, Port and Bypass List

Now let’s retry the script that uses the FQDN of the servers. Yes, life is good again!

image

Figure 5: Remote PowerShell By Using FQDN Style Server Names – Success

YES! Smile

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in System Wide Proxy Settings, Windows Server | 1 Comment »

 
%d bloggers like this: