Using PowerShell to list Zerto Unprotected Systems

This script will connect to the Zerto server and retrieve a list of systems that Zerto is not backing up. The script has been written so that it can function in the Azure Automation or Orchestrator environment. It can also be used as a scheduled task or executed manually. It excludes desktop operating systems.

You will need to install both the activedirectory and zertoapiwrapper modules before using this script.

You can download the script from my GitHub site.

 <#  
      .SYNOPSIS  
           Unprotected Systems Report  
        
      .DESCRIPTION  
           This script will retrieve a list of systems from the Zerto server that are not being backed up. Desktop operating systems and systems not in AD are excluded, as Zerto is typically used for server backup.  
        
      .NOTES  
           ===========================================================================  
           Created with:    SAPIEN Technologies, Inc., PowerShell Studio 2017 v5.4.142  
           Created on:      5/19/2020 5:24 PM  
           Created by:      Mick Pletcher  
           Filename:        ZertoUnprotectedSystems.ps1  
           ===========================================================================  
 #>  
 [CmdletBinding()]  
 param ()  
   
 Import-Module -Name zertoapiwrapper  
 Import-Module -Name activedirectory  
 $Cred = New-Object System.Management.Automation.PSCredential ("domain\username", $password)  
 Connect-ZertoServer -zertoServer prodzerto.wallerlaw.int -credential $Cred  
 $List = (Get-ZertoUnprotectedVm).VmName | Sort-Object  
 $UnprotectedServers = @()  
 Foreach ($System in $List) {  
   Try {  
     $ADComputer = Get-ADComputer $System -Properties OperatingSystem  
     If (($ADComputer.OperatingSystem -notlike '*Windows 7 Enterprise') -and ($ADComputer.OperatingSystem -notlike '*Windows 10 Enterprise')) {  
       $UnprotectedServers += $System  
     }  
   } catch {  
   
   }  
 }  
 #Use this if the script is being used in Azure Automation or Orchestrator  
 Write-Output $UnprotectedServers  
 #Use this if the script is being executed manually, or as a scheduled task.   
 #Send-MailMessage -From '' -To '' -Subject 'Zerto Unprotected Servers' -Body ($UnprotectedServers | Out-String) -Priority High -SmtpServer ''  

Read More

Populate VMWare Virtual Systems to a ConfigMgr Collection

During the COVID19 pandemic, one of my projects has been to build a new configuration manager server at our newer production site for optimal performance. During this process, we needed to be able to differentiate what servers were on our disaster recovery VMWare server, and what servers were on the production VMWare server. We quickly learned that some of the virtual servers could not be differentiated. The only solution we came up with was to use PowerShell to connect to each of the VMWare servers and retrieve a list of machines, which would then populate the Configuration Manager collection.

The following script does just what I described above. You will need to create a collection in Configuration Manager and populate all of the parameter fields. The ConfigMgrModule will need the full UNC path to the PowerShell ConfigMgr Module. The name of the module is ConfigurationManager.psd1. You can do a get-childitem to locate where the .PSD1 file is located. The ConfigMgrSiteDescription parameter can be anything. I suggest executing this on your Configuration Manager server if you set it up as a scheduled task. It can also be executed using Orchestrator or Azure Automation.

NOTE: You will need to download and install the VMWare PowerShell module before executing this script. The following cmdlet will install it.

 Find-Module -Name VMWare.PowerCLI | Install-Module -force -AllowClobber  

You can download this script from my GitHub site. 

 <#  
      .SYNOPSIS  
           Add VMWare systems to specified ConfigMgr collection   
        
      .DESCRIPTION  
           This script will query the VMware server for a list of machines. It will then query Configuration Manager to verify which of those machines are present. Finally, it adds the list of machines to a collection, which is assigned to a specific distribution point.  
        
      .PARAMETER ServerCollection  
           List of servers in Configuration Manager to compare with the list of servers from VMWare.  
        
      .PARAMETER ConfigMgrSiteCode  
           Three letter Configuration Manager site code  
        
      .PARAMETER DistributionPointCollection  
           Name of the collection containing a list of systems on the  
        
      .PARAMETER VMWareServer  
           Name of the VMWare server  
        
      .PARAMETER ConfigMgrModule  
           UNC path including file name of the configuration manager module  
        
      .PARAMETER ConfigMgrServer  
           FQDN of SCCM Server  
        
      .PARAMETER ConfigMgrSiteDescription  
           Description of the ConfigMgr Server  
        
      .NOTES  
           ===========================================================================  
           Created with:    SAPIEN Technologies, Inc., PowerShell Studio 2017 v5.4.142  
           Created on:      5/11/2020 9:50 AM  
           Created by:      Mick Pletcher  
           Filename:        VMWareConfigMgr.ps1  
           ===========================================================================  
 #>  
 [CmdletBinding()]  
 param  
 (  
      [ValidateNotNullOrEmpty()]  
      [string]$AllServersCollection = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$ConfigMgrSiteCode = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$DistributionPointCollection = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$VMWareServer = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$ConfigMgrModule = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$ConfigMgrServer = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$ConfigMgrSiteDescription = ''  
 )  
   
 #Import PowerCLI module  
 Import-Module -Name VMWare.PowerCLI -ErrorAction SilentlyContinue | Out-Null  
 #Collection ID of the collection containing a list of all servers  
 $CollectionID = (Get-WmiObject -Namespace ("root\SMS\site_" + $ConfigMgrSiteCode) -Query ("select * from SMS_Collection Where SMS_Collection.Name=" + [char]39 + $AllServersCollection + [char]39) -ComputerName PRODCM).MemberClassName  
 #Retrieve the list of all servers  
 $MEMCMServerList = Get-WmiObject -Namespace ("root\SMS\site_" + $ConfigMgrSiteCode) -Query "select * FROM $CollectionID" -ComputerName PRODCM | Sort-Object -Property Name  
 #Establish a connection with teh VMWare server  
 Connect-VIServer -Server $VMWareServer | Out-Null  
 $VerifiedServers = @()  
 #Get the list of servers from the VMWare server that are also in Configuration Manager  
 (Get-VM).Name | Sort-Object | ForEach-Object {  
      If ($_ -in $MEMCMServerList.Name) {  
           $VerifiedServers += $_  
      }  
 }  
 #CollectionID of the collection containing a list of all servers in VMWare  
 $CollectionID = (Get-WmiObject -Namespace ("root\SMS\site_" + $ConfigMgrSiteCode) -Query ("select * from SMS_Collection Where SMS_Collection.Name=" + [char]39 + $DistributionPointCollection + [char]39) -ComputerName PRODCM).MemberClassName  
 #Retrieve list of all servers in VMWare ConfigMgr collection  
 $MEMCMServerList = Get-WmiObject -Namespace ("root\SMS\site_" + $ConfigMgrSiteCode) -Query "select * FROM $CollectionID" -ComputerName PRODCM | Sort-Object -Property Name  
 $MissingSystems = @()  
 #Retrieve the list of servers that are not in the ConfigMgr collection  
 $VerifiedServers | ForEach-Object {  
      If ($_ -notin $MEMCMServerList.Name) {  
           $MissingSystems += $_  
      }  
 }  
 If ($MissingSystems -ne $null) {  
      #Import ConfigMgr PowerShell Module  
      Import-Module -Name $ConfigMgrModule -Force  
      #Map drive to ConfigMgr server  
      New-PSDrive -Name $ConfigMgrSiteCode -PSProvider 'AdminUI.PS.Provider\CMSite' -Root $ConfigMgrServer -Description $ConfigMgrSiteDescription | Out-Null  
      #Change current directory to ConfigMgr mapped drive  
      Set-Location -Path ($ConfigMgrSiteCode + ':')  
      #Add missing systems to the specified collection  
      $MissingSystems | ForEach-Object {  
           Add-CMDeviceCollectionDirectMembershipRule -CollectionName $DistributionPointCollection -ResourceID (Get-CMDevice -Name $_).ResourceID  
      }  
 }  

Read More

Configuration Manager 1910 Upgrade Tips and Issues I Encountered

We have a new datacenter and the configuration manager server needed to be moved to that location. The setup of Configuration Manager is not too difficult. I did though run into several gotchas along the way.

• The first one was a warning that read 'configuration for SQL server memory usage'. I needed at least 8 GB of RAM allocated to the SQL database. The following SQL query executed on the ConfigMgr SQL server will rectify that issue. 

 sp_configure 'show advanced options', 1;  
 GO  
 RECONFIGURE;  
 GO  
 sp_configure 'min server memory', 8192;  
 GO  
 RECONFIGURE;  
 GO  

• I ran into the SQL server native client version warning. I fixed that by downloading the SQL Server 2012 Feature Pack which contains sqlncli.msi. That is the native client installer. SQL Server 2019 is the version being used for ConfigMgr 1910. The sqlncli.msi from the 2012 Feature Pack is compatible with SQL Server 2019. 

• When I started using the job migration tool, it seemed to migrate the packages and applications without issue until I went to push them to the new distribution points. That is when I saw the distribution status was still present in the pie charts of the content status. I had to go back and delete the imported items, and then remove them from the distribution points of the old server before migrating them back to the new ConfigMgr server. Once I did that, the newly migrated objects no longer showed false pie charts.

• The final error I got was 'failed to create virtual directory' when I began building my new distribution points. I did not use the old ones, as I wanted them to all be newly built like the ConfigMgr and SQL servers were. The fix to this was to reboot the distribution point server. Once it came back up, the error was gone. 

• I did not know whether I should trying and change the configuration manager clients to point to the new server, or just reinstall them. I ended up running the install client and checking the box to uninstall the old client. That worked perfectly. I chose this method because it would then have all new logs in the %windir%\ccm\logs directory for the new client and nothing left over from the old client. 

I must say that Microsoft has done a fabulous job with the installation process of the new Configuration Manager. This was by far the easiest installation/upgrade I have ever done. I am sure there are a lot more errors and messages others will encounter as every environment is different. The new server is now built and is up and running. 

Read More

ConfigMgr Pending Reboot Report

We wanted a list of servers that are waiting for a reboot. Thankfully, ConfigMgr has a pending restart field that allows admins to see when systems are waiting for a reboot. Our server team wanted that list to be automatically generated and emailed to them daily. Other than myself, others that have the ConfigMgr console rarely look at it since they wear many hats in IT.

I could not find any PowerShell cmdlets in the ConfigMgr module for viewing a pending restart. Thankfully, Eswar Koneti's blog shows the information is stored in sms_combineddeviceresources.

After learning that part, I decided it would be dramatically faster to query the SQL database directly. The table the information resides in is dbo.vSMS_CombinedDeviceResources and is under ClientState. ClientState will have a value of zero if no pending reboot, and a value between 2 and 15 if there is a pending reboot. The list of those values is in the above blog link.

In the PowerShell script below, there are three parameters you will need to populate. The first is $Collection that contains the name of the collection you want to query. $SQLServer is the name of the SQL server. Finally, $SQLDatabase is the name of the ConfigMgr SQL database. You can populate them either at the command line, or hard code the data in the parameter field of the script.

I wrote the script in a way that it can be easily implemented into Azure Automation, SMA, or Orchestrator. The script will output the list of machines waiting for a reboot using the Write-Output and Exit with a return code of 1 if there is nothing to report. The exit code 1 is used with Orchestrator or SMA for the Link between the PowerShell script and the email. The link would not continue to the email task if there were an exit code of 1, as shown below.

NOTE: For this to access the SQL server, the script must be executed on the SQL server, or on a machine that has the SQL console. This is required, so PowerShell has access to the SQL PowerShell module.

You can download this script from my GitHub site.

 <#  
      .SYNOPSIS  
           ConfigMgr Reboot Report  
        
      .DESCRIPTION  
           This script will query ConfigMgr for a list of machines that are waiting for a reboot.  
        
      .PARAMETER Collection  
           Name of the collection to query  
        
      .PARAMETER SQLServer  
           Name of the SQL server  
        
      .PARAMETER SQLDatabase  
           A description of the SQLDatabase parameter.  
        
      .PARAMETER SQLInstance  
           Name of the SQL Database  
        
      .PARAMETER SCCMFQDN  
           Fully Qualified Domain Name of the ConfigMgr server  
        
      .NOTES  
           ===========================================================================  
           Created with:     SAPIEN Technologies, Inc., PowerShell Studio 2017 v5.4.142  
           Created on:       05/01/2020 09:39 AM  
           Created by:       Mick Pletcher  
           Filename:         ConfigMgrRebootReport.ps1  
           ===========================================================================  
 #>  
 [CmdletBinding()]  
 param  
 (  
      [ValidateNotNullOrEmpty()]  
      [string]$Collection = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$SQLServer = '',  
      [ValidateNotNullOrEmpty()]  
      [string]$SQLDatabase = ''  
 )  
   
 $RebootListQuery = 'SELECT * FROM dbo.vSMS_CombinedDeviceResources WHERE ClientState <> 0'  
 $RebootList = (Invoke-Sqlcmd -ServerInstance $SQLServer -Database $SQLDatabase -Query $RebootListQuery).Name | Sort-Object  
 $CollectionQuery = 'SELECT * FROM' + [char]32 + 'dbo.' + ((Invoke-Sqlcmd -ServerInstance $SQLServer -Database $SQLDatabase -Query ('SELECT ResultTableName FROM dbo.v_Collections WHERE CollectionName = ' + [char]39 + $Collection + [char]39)).ResultTableName)  
 $CollectionList = (Invoke-Sqlcmd -ServerInstance $SQLServer -Database $SQLDatabase -Query $CollectionQuery).Name | Sort-Object  
 $List = @()  
 $RebootList | ForEach-Object { If ($_ -in $CollectionList) { $List += $_ } }  
 If ($List -ne '') {  
      Write-Output $List  
 } else {  
      Exit 1  
 }  
   

Read More

Configuration Manager Default Antimalware Policy

While building my new Configuration Manager server, MECM, I took screenshots of the default antimalware policy settings in the event settings in it ever got changed. The default should not be changed. A new policy should be created and deployed.

Scheduled Scans

Scan Settings

Default Actions

Real-time Protection

Exclusion Settings

Advanced

Threat Overrides

Cloud Protection Service

Security Intelligence Updates

Read More

Configuration Manager Default Client Settings

I just started building a completely new configuration manager server. While setting it up, I remembered that I wished in the past that I had all of the original default client settings because some did get changed. If you have ever made changes directly to the default client settings and cannot remember what the original settings were, then here is a screenshot of each section.

Background Intelligent Transfer

Client Cache Settings

Client Policy

Cloud Services

Compliance Settings

Computer Agent

Computer Restart

Delivery Optimization

Endpoint Protection

Enrollment

Hardware Inventory

Metered Internet Connections

Power Management

Remote Tools

Software Center

Software Deployment

Software Inventory

Software Metering

Software Updates

State Messaging

User and Device Affinity

Windows Analytics

Read More

Upgrading to both Windows 10 1903 and 1909 with Configuration Manager

The time has come to do another creator update to the corporate systems. We skipped the 1903 upgrade because of the Windows 7 to Windows 10 deployment that completed just after the release of 1903. It was too soon to start another creator update project, so we waited until 1909. One of the new features we are wanting is the reserved space that was introduced in 1903. This reserves seven gigabytes of data for future updates and upgrades. The feature is set by default when an OS is installed during a build. It has to be turned on after the OS is deployed during an upgrade via a registry key. The problem is that once the key is set to one, the reserved space does not take effect until the next creator update. Another major issue I had was that the task sequence can only execute one OS upgrade at a time. This is because once the upgraded OS is installed, it will continue running the same task sequence during the upgrade process. The screenshot below shows where it executes the rest of the task sequence. There is no way to circumvent this process. If it continues with the following OS install, the task sequence errors out.

To get both OSs installed within the same task sequence, I set up the EndTS variable that stops the second install if the first one has executed. This means the same task sequence will need to be run twice to install both versions. The trick is to set the Rerun behavior to Rerun if succeeded on the previous attempt, as shown below. This allows for the task sequence to be executed a second time. It will skip over the first upgrade, 1903, and go right to 1909. If 1909 is already installed and the task sequence reruns, the top-level folder sequence will prevent it from executing any other tasks. The other trick to stop this from running again after both installs are complete is to have the collection filter out systems that have 1909 installed.

The first thing you want to do is to import the desired Windows 10 versions as an Operating System Upgrade in the configuration manager. Once the OS Upgrades are imported, one thing you might want to consider is copying the content to a distribution share so that you can access the package in remote offices in the event of an OS upgrade failure, as shown below. This will allow you to be able to manually execute the install on a failed machine remotely for further troubleshooting.

Next will be creating the task sequence. You will want to create a new task sequence to upgrade an operating system from an upgrade package.

Stepping through the process of creating this task sequence is self-explanatory. I am going to include screenshots of each screen.

Here is what the task sequence looks like after I got it set up and added all of the necessary features. Your task sequence will likely be somewhat different, as every company has a unique configuration.

This is the conditional WMI query I use for the top-level Upgrade folder. This is so if the latest OS version is already installed, then it will skip over all other task sequences.

The next thing I have it do is to set the task sequence variable EndTS to 0. This variable is used to skip over the second OS upgrade if the first one runs. It does this by including a task sequence under the first OS upgrade that sets the variable to one. When the second OS upgrade task sequence is executed, there is a rule to only run if the EndTS equals zero.

The PowerShell 7 upgrade is next and simply run the PowerShell 7 application installation.

Here are the specs for the Check Readiness for Upgrade:

One of the specifications we have is that laptops are left in the office and docked. The following PowerShell script does just that as a condition for continuing the task sequence:

I had a lot of problems getting the cleanmgr.exe to work and was never successful. I saw on several sites where others had the same issue. I ran across Fabian Castagna's PowerShell script that does much of the same as cleanmgr.exe does. I could never get it to delete the windows.old folder, but I have a solution further on in this blog.

For the first upgrade, Upgrade the Operating System to 1903, I used the WMI filter so that it will only install it if the OS is older than 1903.

The next step is installing the OS. This step readies the system for the actual upgrade that takes place in the proceeding reboot.

The reboot step will restart the system, at which point the actual upgrade will take place. The OS does not load in this step. I have a 60 second wait time along with a message in the event a user is on the system at 1:00 am when the task sequence starts.

The next sequence is to Enable Reserved Storage. This is where a registry key is set that enables this feature upon the next upgrade.

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ReserveManager /v ShippedWithReserves /t REG_DWORD /d 1 /f

The next sequence reruns the disk cleanup script.

Next comes deleting the Windows.old directory. I worked on this for quite a while. It is not easy to do if you can't automate cleanmgr.exe. It ended up being a hit or miss thing. Sometime the script I had written would work, other times, it either was unsuccessful, or it crashed the OS when it deleted the files still being used as a service. What I came up with was to remove the entire folder at once within WinPE. The OS does not load, so no files are in use, thereby allowing for the complete deletion.

The first thing is to boot into WinPE.

The next step is to delete the folder using the following PowerShell code:

 $Drive = Get-PSDrive | Where-Object {($_.Provider -like 'Microsoft.PowerShell.Core\FileSystem*') -and ($_.Description -like 'Windows*')}  
 If (Test-Path ($Drive.Root + 'Windows.old')) {  
      $Argument = '/c RMDIR.exe' + [char]32 + '/S /Q' + [char]32 + $Drive.Root + 'Windows.old'  
      $ExitCode = (Start-Process -FilePath ($env:windir + '\system32\cmd.exe') -ArgumentList $Argument -PassThru -WindowStyle Minimized -Wait).ExitCode  
 }  

Next comes a reboot using the currently installed OS.

Now comes setting the EndTS variable to 1, so the following OS upgrade does not execute.

The next step is the 1909 upgrade. The only differences in this compared to the 1903 update are:

• The Task sequence variable will be a condition set for the top-level folder of this task sequence
• Enable Reserved Storage task sequence is not needed
• End Task Sequence is also not required. 

Here are the conditions to run this set of task sequences that are set on the Upgrade the Operating System to the 1909 folder. We don't want this to execute unless 1903 is installed, and we don't want it to run if the task sequence just installed 1903. 

Read More