Powershell Scrip to Run SCCM Action under Configuration Manager Properties

Run the following script in powershell to run the Action items.

Function Run-SCCMClientAction {
        [CmdletBinding()]
               
        # Parameters used in this function
        param
        (
            [Parameter(Position=0, Mandatory = $True, HelpMessage="Provide server names", ValueFromPipeline = $true)]
            [string[]]$Computername,

           [ValidateSet('MachinePolicy',
                        'DiscoveryData',
                        'ComplianceEvaluation',
                        'AppDeployment', 
                        'HardwareInventory',
                        'UpdateDeployment',
                        'UpdateScan',
                        'SoftwareInventory')]
            [string[]]$ClientAction
  
        )
        $ActionResults = @()
        Try {
                $ActionResults = Invoke-Command -ComputerName $Computername {param([string[]]$ClientAction)

                        Foreach ($Item in $ClientAction) {
                            $Object = @{} | select "Action name",Status
                            Try{
                                $ScheduleIDMappings = @{
                                    'MachinePolicy'        = '{00000000-0000-0000-0000-000000000021}';
                                    'DiscoveryData'        = '{00000000-0000-0000-0000-000000000003}';
                                    'ComplianceEvaluation' = '{00000000-0000-0000-0000-000000000071}';
                                    'AppDeployment'        = '{00000000-0000-0000-0000-000000000121}';
                                    'HardwareInventory'    = '{00000000-0000-0000-0000-000000000001}';
                                    'UpdateDeployment'     = '{00000000-0000-0000-0000-000000000108}';
                                    'UpdateScan'           = '{00000000-0000-0000-0000-000000000113}';
                                    'SoftwareInventory'    = '{00000000-0000-0000-0000-000000000002}';
                                }
                                $ScheduleID = $ScheduleIDMappings[$item]
                                Write-Verbose "Processing $Item - $ScheduleID"
                                [void]([wmiclass] "root\ccm:SMS_Client").TriggerSchedule($ScheduleID);
                                $Status = "Success"
                                Write-Verbose "Operation status - $status"
                            }
                            Catch{
                                $Status = "Failed"
                                Write-Verbose "Operation status - $status"
                            }
                            $Object."Action name" = $item
                            $Object.Status = $Status
                            $Object
                        }

            } -ArgumentList (,$ClientAction) -ErrorAction Stop | Select-Object @{n='ServerName';e={$_.pscomputername}},"Action name",Status
        } 
        Catch{
            Write-Error $_.Exception.Message
        }  
        Return $ActionResults          
 }   
 Run-SCCMClientAction -ComputerName localhost -ClientAction MachinePolicy,DiscoveryData,ComplianceEvaluation,AppDeployment,HardwareInventory,UpdateDeployment,UpdateScan,SoftwareInventory

PowerShell Basics: How to Force AzureAD Connect to Sync

 

In every organization, the possibility of role changes or change of contact information can occur quite frequently. AzureAD Connect is a great tool that allows administrators to make said updates either on-premises or in cloud and will sync all changes accordingly. It can take up to 30 minutes for Azure Active Directory to update these changes when these changes are applied on the on-premises Active Directory instance and vice-versa via AzureAD Connect. It can also take up to an additional 30 minutes to then sync changes with Office 365. This post will detail steps to force AzureAD Connect to sync on command when required via PowerShell to combat the delay.

   

Lets begin.

   

1. Run PowerShell
    
   Run PowerShell
    
2. Run the following command to install the AzureAD Sync module:
    

   Import-Module ADSync

3. Next lets review the current intervals AzureAD Connect uses to sync by running the following command.
    

   Get-ADSyncScheduler

   NOTE: The report should show intervals of 30 minute syncs and a sync policy type of Delta. A sync policy type of Initial is usually shown after AzureAD Connect's initial sync but can also be forced as detailed in the next step.
    
4. Now run the following command to initialize the AzureAD Sync immediately.
    

   Start-ADSyncSyncCycle -PolicyType Delta

 

Domain Controller Selection

The process of a Windows client selecting an Active Directory domain controller isn't too complex but is often not fully understood.  Let's look at the way a member server chooses a DC and how this affects applications.

Why it Matters

Windows will optimize connections to the best available domain controller for the following types of situations:

• Authentication for users logging directly into the server
• Authentication for users accessing the applications on the server (such as SharePoint or Exchange)
• Group policy processing for user accounts and the computer account
• Promotion of a member server to a DC

For each of these, it is clearly important to try to use a DC that is local to the member server.  For example, you wouldn't want thousands of Exchange authentications to be sent to a DC across the country if a local one is available.

How it Works

When a member server or workstation needs to find a domain controller, it goes through the following steps:

1. Query the primary DNS server for the all domain controller SRV records in the domain (These have the format of "_ldap._tcp.mydomain.local")
   1. This will return an entry for each DC in the domain.  For example, this screenshot shows the lookup result for a domain with 2 DCs, named MGLABDC4 and MGLABDC5:
      
2. Select the first DC in DNS result list and connect to it via LDAP
3. Determine if the chosen DC is in the same site as the member server, based on the information configured in AD Sites & Services
   1. If so, the member server begins using that DC for communications
   2. If not, the DC tells member server what site it is in
      1. Member server sends new DNS query for the list of DCs specifically in its own site
      2. Member server selects the first DC in DNS result list and connects to it via LDAP
      3. If no DC in the local site is available, connect to any DC in the domain
4. Cache the name of the local site in the registry to speed up future operations

If the client attempts to contact a DC that's offline, it will try to contact the next one in the list until all results are exhausted.

Here is a screenshot from a member server showing how the server is preferring the DC in its local site.


A common misconception is that Windows clients will use their configured DNS servers as their primary DCs.  As you can see by the above process, this is not the case.  The member server will query its configured DNS server to retrieve a list of DCs and then intelligently choose the correct DC based on the site information.

Commands to Help

To help view and diagnose how a member server is locating its DC, try the following commands

echo %logonserver% - This shows the DC that was used to authenticate and log in the current user


nltest /dsgetsite - This shows the AD site that the current server has detected that it's in


nltest /dclist: (include the colon at the end) - This shows the list of DCs in the current domain, including which site each is in.  In this example, MGLABDC4 is in the MG-AZ-EASTUS site, and MGLABDC5 is in the MG-AZ-EASTUS2 site.


nslookup -type=srv _ldap._tcp.mydomain.local. - This will query the primary DNS server for all domain controller SRV records.  This should return all of the DCs in the domain.  In this example, MGLABDC4 and MGLABDC5 are returned.


nslookup -type=srv _ldap._tcp.mysitename._sites.dc._msdcs.mydomain.local. - This will query the primary DNS server for domain controllers that are registered in "mysitename".  In this example, only MGLABDC4 is in the site that was queried, which matches the information we found with nltest /dclist: previously.

 

 

Configuration

How do you ensure that all of this happens smoothly?  The single most important thing to check is that AD Sites & Services is configured correctly.  You should review and confirm the following points:

• All of the LAN subnets in the corporate network are defined in AD Sites & Services
• Each of those subnets is configured for the correct AD Site
• Each site with a significant number of clients has a local DC to authenticate with

If the Windows client's IP address doesn't match to a subnet defined in the AD configuration, it has no way of finding a the closest DC.  That can lead to unoptimized connections and slower logons and AD operations.

How to point a client to different Domain Controller

 

When a logon request is made to a domain, the workstation sends out a request to find a domain controller for the domain. The domain name is actually a NetBIOS name that is a 16-character name with the 16th character used by Microsoft networking services to identify the NetBIOS type.

For some reason some clients are not working as expected or working slower and you want to point client to different domain controller. To find out if any of the domain controllers is having problems you can quickly change the domain controller that the affected client is using.

Back in the day when Windows NT 4 ruled the world there was a command called setprfdc (set preferred domain controller) nltest does something similar.

So first we wanted to find out what DC the client is using. Now there are many different ways but here is a command that generally used:

nltest /dsgetdc:domain.local

The output was:

DC: \\DC1.DOMAIN.local
Address: \\10.111.1.200
Dom Guid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Dom Name: DOMAIN.local
Forest Name: DOMAIN.local
Dc Site Name: Default-First-Site-Name
Our Site Name: Interxion
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST
The command completed successfully.


This means that the client is using DC1. Now we wanted quickly to point the client to a different domain controller DC2. To do that write the following command:

nltest /Server:client0 /SC_RESET:domain.local\dc2

The output was:  

Flags: 30 HAS_IP  HAS_TIMESERVTrusted DC Name \\DC1.DOMAIN.local
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully


 If you run the first command again you should see that domain controller has changed.