Thomas' Tech Talk

Just Can't Get Enough Of IT

Start Scheduled Tasks Remotely

Filed under: Exchange Server,PowerShell — Thomas Stensitzki at 4:00 pm on Saturday, July 18, 2020  Tagged

When you maintain a number of servers which require to trigger the same scheduled task manually, you can simply the process by triggering the scheduled task remotely.

In this example, I assume that the script is being executed on a dedicated management server (aka job server) within an Exchange Server 2013 environment. The scheduled task must exist on all servers having the same name.

Create a simple PowerShell script at a file location of your choice (i.e. D:\Scripts\Start-RemoteScheduledTasks.ps1)

$cimSession = New-CimSession -ComputerName SERVER1,SERVER2,SERVER3,SERVER4

Start-ScheduledTask TASKNAME -CimSession $cimSession

Remove-CimSession $cimSession

Now create a new shortcut on your server desktop with the following configuration:

Target: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command “& D:\Scripts\Start-RemoteScheduledTasks.ps1” 

If required, select “Run as Adminstrator” in the Shortcut -> Advanced settings.



This post was previously published on my legacy SF-Tools blog.
Original publishing date: 2015-02-26

The local machine is not an Exchange server

Filed under: Exchange Server — Thomas Stensitzki at 4:00 pm on Thursday, July 16, 2020  Tagged ,

While trying to get public folder statistics on an Exchange 2007 server I came across the following error: The local machine is not an Exchange server.

Screenshot - The local server is not an Exchange Server


Get-PublicFolderStatistics : The local machine is not an Exchange server. Please specify the name of a Mailbox server.
At line:1 char:75
+ Get-PublicFolder “\PUBLICFOLDER” -Recurse | Get-PublicFolderStatistics <<
+ CategoryInfo          : NotSpecified: (0:Int32) [Get-PublicFolderStatistics], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : AFC2C5CC,Microsoft.Exchange.Management.MapiTasks.GetPublicFolderStatistics


In this case, the solution was pretty simple. I tried to fetch the public folder statistics on the passive node of the cluster. Even though the Exchange cmdlet Get-PublicFolder “\FOLDER” –Recurse was executed successfully, receiving the public folder statistics failed.

Executing the same query on the active node was successful.


Enjoy Exchange Server.



This post was previously published on my legacy SF-Tools blog.
Original publishing date: 2015-02-28

Create Migration Batches With Common Parameters

Filed under: Exchange Server,PowerShell — Thomas Stensitzki at 2:57 pm on Tuesday, July 14, 2020  Tagged ,

This is a community PowerShell script to simplify Exchange Server mailbox migrations and is available on Github.


  • Validate CSV file for required column EmailAddress prior to creating migration batch in Exchange
  • Automatic batch naming based on CSV file name
  • Common notification email address settings
  • Variable AutoComplete of batches
  • Common logging of script activities



Migrate users configured in in CSV file MyBatchFile.csv and complete migration automatically

.\Move-MailboxesAsBatch.ps1 -CSVFile .\MyBatchFile.csv -AutoComplete

Migrate users configured in in CSV file MyBatchFile.csv, allow 10 bad items, notify and do not complete migration automatically

.\Move-MailboxesAsBatch.ps1 -CSVFile .\MyBatchFile.csv -BadItemLimit 10 -NotificationEmails @("")



This post was previously published on my legacy SF-Tools blog.
Original publishing date: 2015-07-17

Unable to download NuGet package provider

Filed under: PowerShell,Windows Server — Thomas Stensitzki at 4:38 pm on Thursday, June 11, 2020  Tagged

When you try to install a module from PowerShell Gallery using the Install-Module cmdlet it might fail.

Installing a PowerShell module requires the NuGet package provider installed first. Installing the package provide might fail as well with the following error:

WARNING: Unable to download from URI ‘’ to ”. WARNING: Unable to download the list of available providers. Check your internet connection. PackageManagement\Install-PackageProvider : No match was found for the specified search criteria for the provider ‘NuGet’. The package provider requires ‘PackageManagement’ and ‘Provider’ tags. Please check if the specified package has the tags. At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\\PSModule.psm1:7405 char:21 + … $null = PackageManagement\Install-PackageProvider -Name $script:N … + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (Microsoft.Power…PackageProvider:InstallPackageProvider) [Install-Pac kageProvider], Exception + FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro vider PackageManagement\Import-PackageProvider : No match was found for the specified search criteria and provider name ‘NuGet’. Try ‘Get-PackageProvider -ListAvailable’ to see if the provider exists on the system. At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\\PSModule.psm1:7411 char:21 + … $null = PackageManagement\Import-PackageProvider -Name $script:Nu … + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidData: (NuGet:String) [Import-PackageProvider], Exception + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.ImportPackageProv ider



The installation fails because the server’s .NET Framework is not configured for the use of TLS 1.2.



Enable TLS 1.2 for your current PowerShell session using the follow command:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12



Add two registry keys to enable the use of TLS 1.2 for 32- and 64-bit .Net Framework libraries.

  • 32-bit
    • Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord
  • 64-bit
    • Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord


Enjoy PowerShell!



User Group Membership – Quick Query

Filed under: On-Premises — Thomas Stensitzki at 11:26 am on Monday, March 23, 2020  Tagged ,

You sometimes need to know the Active Directory domain group memberships of a user currently logged in to a Windows computer. Mostly, you need this information for troubleshooting purposes.

The easiest way is using the following command line query:

net user /domain %username%


C:\>net user /domain %username%
User name varadmin
Full Name Varuna Admin
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never

Password last set 22.01.2016 10:09:53
Password expires Never
Password changeable 23.01.2016 10:09:53
Password required Yes
User may change password Yes

Workstations allowed All
Logon script
User profile
Home directory
Last logon 22.03.2020 18:08:15

Logon hours allowed All

Local Group Memberships *ADSyncAdmins
Global Group memberships *NoSpamProxy People an*NoSpamProxy Monitorin
                         *Foresite_Admins *Compass_Admins
                         *NoSpamProxy Disclaime*Enterprise Admins
                         *Mailscape_Users *Group Policy Creator
                         *Organization Manageme*Compass_Users
                         *Foresite_Users *Mailscape_Admins
                         *Schema Admins *Domain Admins
                         *NoSpamProxy Configura*Domain Users

The command completed successfully.



Move FSMO Roles in Windows Server 2019

Filed under: On-Premises,Windows Server — Thomas Stensitzki at 11:34 am on Saturday, March 21, 2020  Tagged , ,

In the past, we’ve used NETDOM to identify FSMO-systems and to move assigned FSMO-roles to other Windows Server systems.

With Windows Server 2016 or newer you can use PowerShell to easily move FMSO-roles to a new domain controller.


Move a single FSMO-role to a new domain controller

Move-ADDirectoryServerOperationMasterRole -Identity DC01 `
-OperationMasterRole RIDMaster


Move all FSMO-roles to a new domain controller

Move-ADDirectoryServerOperationMasterRole -Identity DC01 `
-OperationMasterRole PDCEmulator,InfrastructureMaster,SchemaMaster,`


Read more about the cmdlet and all supported parameters in cmdlet-documentation.




Thomas’ Tech Talk – Overview

Filed under: Exchange Online,Exchange Server,Video — Thomas Stensitzki at 10:00 am on Saturday, March 14, 2020  Tagged

Thomas’ Tech Talk – YouTube Channel

Overview of my YouTube recordings (in German).


  • Tech Talk 1: Supportende von Exchange Server 2010
    Cover Thomas' Tech Talk 1 - Supportende von Exchange Server 2010
  • Tech Talk 2: Migration von Exchange Server zu Exchange Online
    Cover Thomas' Tech Talk 2 - Migration von Exchange Server zu Exchange Online
  • Tech Talk 3: Exchange Hybrid
    Cover Thomas' Tech Talk 3 - Exchange Hybrid
  • Tech Talk 4:
    Cover Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?



Purge-LogFiles updated to v2.3

Filed under: Exchange Server,PowerShell — Thomas Stensitzki at 6:35 pm on Thursday, March 12, 2020  Tagged , , ,

The PowerShell script to purge log files of modern Exchange Server editons has been updated to version 2.3.

The new version supports:

  • dynamic Exchange Server installation paths across multiple servers
  • deletion of the HTTPERR folder
  • HTML formatting for email notification email

Additionally, the script is tested with Exchange Server 2019.

You can download the source at GitHub or TechNet Gallery.

Please vote for the script at TechNet Gallery, and post comments, issues, and feature requests at GitHub.


Select non-default receive connectors

Filed under: Exchange Server,PowerShell — Thomas Stensitzki at 8:46 pm on Sunday, March 8, 2020  Tagged

Sometines you want to select all non-default receive connectors for further processing in PowerShell. The following simple example selects all receive connectors excluding the connectors using server name as part of the connector name.

When querying the receive connectors for a server you will get all configured connectors.

Get-ReceiveConnector -Server $Server | ft -AutoSize

Identity                                  Bindings Enabled
--------                                  -------- -------
DEHVNEX1\Default DEHVNEX1                 {, [::]:2525} True
DEHVNEX1\Client Proxy DEHVNEX1            {[::]:465,}   True
DEHVNEX1\Default Frontend DEHVNEX1        {[::]:25,}     True
DEHVNEX1\Outbound Proxy Frontend DEHVNEX1 {[::]:717,}   True
DEHVNEX1\Client Frontend DEHVNEX1         {[::]:587,}   True
DEHVNEX1\Anonymous Relay                  {}              True
DEHVNEX1\From Veruna-BER                  {}              True
DEHVNEX1\APPS-Relay                       {}              True


The following PowerShell query excludes the receive connectors as mentioned.


Get-ReceiveConnector -Server $Server | `
?{(([string]$_.Identity).Split('\')[1]) -notlike "*$($Server)*"} | `
ft -AutoSize

Identity                 Bindings     Enabled
--------                 --------     -------
DEHVNEX1\Anonymous Relay {} True
DEHVNEX1\From Veruna-BER {} True
DEHVNEX1\APPS-Relay      {} True


If you want to reuse the filtered output for further processing, simply store the output in a variable, e.g., $ReceiveConnectors.

$ReceiveConnectors=Get-ReceiveConnector -Server $Server | `
?{(([string]$_.Identity).Split('\')[1]) -notlike "*$($Server)*"}


This is a basic example and should encourage you to extend it to fit your needs in your Exchange Server environment.

Enjoy Exchange Server.

The Stepchild of Exchange Server – The Edge Transport Role

Filed under: Exchange Server — Thomas Stensitzki at 9:47 pm on Sunday, February 16, 2020

Exchange 2019 - Edge Transport Role Icon

The Exchange Edge server role was introduced with Exchange Server 2007. Back in those days, it was State-Of-The-Art to terminate protocol connections in the perimeter network, preferably on servers not being member servers of an internal Enterprise Active Directory.

The Edge server role had been introduced by the Exchange product team to meet this design pattern. Shortly after the initial product launch first Best Practices had been published, describing the optimal deployment options for the new messaging transport role. The adoption rate of the new server role was very low in the beginning. This was mostly due to the technical requirements (e.g. subscription of the Edge server to a dedicated AD site containing Hub transport servers) and to slowly introduced Exchange Server virtualization. Nobody wanted to waste additional hardware resources for an Exchange server role providing so little benefit. This was a kind of technology that was only useful to large enterprises.

Since the Edge server role got introduced there are constant discussions between Messaging Administrators, who want to avoid additional levels of complexity to their Exchange infrastructure, and Security Administrators, who do not allow direct protocol communication originating from the Internet to internal servers (in this case Hub transport servers).

One of the major benefits of an Edge server, from a security standpoint, is the fact that the server is not a member server of an Active Directory Domain. In addition all required information about internal recipients, block- and allow lists are stored encrypted in an AD LDS instance. Updates are pushed from internal servers using the encrypted Edge-Sync.

The RTM release of Exchange Server 2010 included a new version of the Edge server role. There haven’t been any new major features, besides some minor functionality enhancements. The primary feature set remained unchanged:

  • Email filtering
  • Anti-Spam and Anti-Virus
  • Dedicated connectors to partners
  • Connectors using Domain Validation
  • Connectors using Domain Secure, which shows green tick in Outlook when a message has been received via such a secured connector
  • Integration with Office 365
  • Delayed Acknowledge for incoming messages to support Shadow Redundancy
  • Address rewriting

Some of these features are available with properly configured Hub transport servers as well. But as already mentioned, it is a question of transport layer security. Some administrators trust protocol inspection technologies provided by modern firewalls (without naming any specific brand or model). Where do you want to have your attackers end up first? In your perimeter network, right? Otherwise, there is no need for a perimeter network.

With Exchange Server 2013 Microsoft missed providing the Edge server role with the initial RTM release. Instead, it was fully supported to operate internal Exchange 2013 servers with Exchange 2007 or Exchange 2010 server. This “mixed” operating mode was not well accepted, because nobody really wanted to operate and maintain such a configuration. With the release of the so-called Exchange Server 2013 SP1 a bunch of missing Exchange features had been made available including the Edge server role.

Exchange Server 2016 and Exchange Server 2019 support the Edge Transport role as well. The technology stack of the Exchange transport role has not much changed. The reason is that there is not much that needs to be changed.

Is there a need for the Exchange Server Edge Transport Role today?

Yes, we do need the Edge server role these days. The Edge server role provides dedicated endpoints for messages received from and sent to the internet. Such central endpoints provide a starting point for message transport-related support issues. Two Edge servers provide a good redundancy for message flow. Internal Hub transport servers can be scaled as needed. There are no specific system requirements for Edge transport servers that would avoid virtualization. The Edge server role, like the Hub transport role from previous Exchange versions, is a perfect candidate for being virtualized.

Mergers are a perfect example where the Edge server role shows its benefit. Merger situations are always characterized by the need to introduce a new email domain to external recipients as quickly as possible. This should be done without any major technical problems. The expectations expressed by the marketing department are met with resistance from the IT department.  The Edge server role supports such requirements by utilizing the address rewriting capabilities.

But wait, there is another important reason why we need the Edge Transport Role. Edge Server comes into play when you implement an Exchange Server hybrid setup. The supported setup for connecting your on-premises Exchange organization with Exchange Online requires an SMTP-communication flow between Exchange servers. The internal Exchange Servers are domain member servers. Any incoming SMTP-connection must terminate in the perimeter network. The Edge Server is the perfect candidate for this scenario. The use of Edge Server in the perimeter network secures the hybrid mail-flow regardless if you use centralized mail-flow or not.

Even today there are valid reasons for deploying the Exchange Edge Server role.




Next Page »