This scripts checks multiple Exchange Server 2013 OWA web.config files for existence of IMCertificateThumbprint and IMServerName Xml nodes required for Skype for Business OWA integration.
This mostly required after installing a new Exchange Server Cumulative Update.
IMServerName is the FQN of the Front End Pool
IMCertificateThumbprint is the certificate thumbprint of the Exchange OWA certificate
Exchange Server 2016 stores the IM information in Active Directory.
# Update all OWA web.config files to Skype for Business FE Pool myfepool.varunagroup.de and thumbprint .\Set-OwaIMSettings.ps1 -FrontEndPoolFqdn myfepool.varunagroup.de -CertificateThumbprint "1144F22E9E045BF0BA421CAA4BB7AF12EF570C17"
Additional credits go to Juan Jose Martinez Moreno
When you've enabled the Exchange scripting agent extension agents, it is required to copy the configuration file to each Exchange server. Paul Cunningham's script helps you to achive this goal pretty easily.
But if you have installed the Exchange 2013 Management Tools on additonal servers, these servers are not fetched using the Get-ExchangeServer cmdlet. But when you install a Cumulative Update the existence of the extension agent config file is checked. And this even on a server having only the Exchange Management Tools installed.
Therefore the following PowerShell code provides an easy and simple way to add additonal server having the Exchange 2013+ Management Tools installed (aka Admin Servers, Monitoring Servers, Job Servers, etc.). The script uses a filter to select Exchange 2013 servers only, as the script has been extended in an environment having still active Exchange 2007 servers.
The following PowerShell snippet displays only the changes, which need to be added to Paul's original script starting row 68.
# Original PowerShell code # $exchangeservers = Get-ExchangeServer # Select all Exchange 2013 servers only, restrict properties to Name and AdminDisplayName $exchangeservers = Get-ExchangeServer | ?{$_.AdminDisplayVersion -like "Version 15.0*"} | Select Name, AdminDisplayVersion # Add additional servers as needed $manualServers = @() # Copy and modify as needed $manualServers += (New-Object PSObject -Property @{Name="EXSRV2010";AdminDisplayVersion="Version 14"}) $manualServers += (New-Object PSObject -Property @{Name="EXSRV2013-01";AdminDisplayVersion="Version 15"}) $manualServers += (New-Object PSObject -Property @{Name="EXSRV2013-02";AdminDisplayVersion="Version 15"}) # Combine arrays $exchangeservers = $exchangeservers + $manualServers # End Modification $report = @() [string]$date = Get-Date -F yyyyMMdd-HHmmss
Enjoy extending the Exchange PowerShell cmdlets.
Questions? Just leave a comment.
These are the results of the Exchange Server Questionnaire from August 2021.
First of all, I want to thank all of you who participated in the questionnaire. The results are pretty interesting. Even though, that the results are not 100% representative they provide a high-level view of the Exchange Organizations, the mail flow configurations, and the future plans regarding hybrid and Exchange Online.
With 55 replies the questionnaire is far from being a comprehensive representation of the Exchange organizations. But the answers provide an idea of the Exchange landscape used by organizations globally.
Exchange Server 2016 is the dominant version currently in use, followed by Exchange Server 2019. The vast majority of 93% runs modern Exchange Server versions. But there are still older and unsupported Exchange Server versions in use. 7% use Exchange Server 2010 and older.
76% of the organizations maintain up to ten Exchange servers. 20% prefer to rely on just one Exchange server. It is interesting that only 2 (not percent) plan to go hybrid or to move to Exchange Online.
The majority of on-premises Exchange organizations are in the 1,000 - 10,000 mailboxes range. Nevertheless, the SMBs with 1 to 1,000 mailboxes adds up to 50% of the Exchange organizations that took part in this questionnaire. There are just a few organizations that host more than 50,000 mailboxes.
There are Exchange organizations that do not use an SMTP-Gateway solution as part of the mail-flow implementation. Thor organizations that do not use a gateway solution run 1 to 10 Exchange servers on-premises. The majority of those have less than 1,000 mailboxes but there are a few that are responsible for more than 1,000 mailboxes. That leaves the question of why an organization prefers to not secure mal-flow with a gateway.
The use of SMTP gateways is a must, as you do not want to expose your domain member servers to the Internet, not even for the SMTP protocol. A majority of 28 answers for other gateways shows, that there are so many products available and that I did not choose valid answer options upfront.
The Other answers include:
65% of the Exchange organizations of this questionnaire already run in a hybrid configuration with Exchange Online. Only 35% are (still) not using a hybrid setup.
Of those who currently do not run a hybrid configuration only 37% plan on implementing Exchange Hybrid or migrate fully to Exchange Online. Staying on-premises is the only option.
The majority of the organizations still running only an on-premises Exchange organization plan on implementing Exchange Hybrid or migrating to Exchange Online by the end of 2021. None of the participating organizations has plans scheduled after 2022.
It is no surprise that Classic Full Hybrid is the most adopted hybrid configuration. And, no surprise either, none of the other classic hybrid options is implemented. The modern hybrid approach is implemented but with lesser.
The reasons for staying with an on-premises Exchange organization vary. the reasons mentioned are:
There are still organizations that choose an on-premises Exchange organization in favor of Exchange Online. I wonder if company policies for reducing the carbon footprint might drive the migration of on-premises data center resources to hosted cloud services.
Exchange Server vNEXT is in scope for 47% of the organizations. When comparing it with the used Exchange Server version currently in use (~50% Exchange Server 2016) it is an indicator that some companies just skip Exchange Server 2019. Some organizations prefer not to follow the full life-cycle of Exchange Server. s7% of those who do not want to implement Exchange Server vNEXT and want to stay on-premises are single server implementations of Exchange.
The product Exchange Server is still widely used in on-premises deployments. The reasons vary from legal and compliance requirements, network bandwidth constraints, and the overall costs for Exchange Online. Exchange Server vNEXT is a must-have for nearly 50% of the organizations participating in this questionnaire. There are still older and unsupported versions in productive use. Why this is the case is unanswered in this questionnaire.
Organizations running a hybrid Exchange configuration primarily use a Classic Full Hybrid configuration. This might be due to an early implementation in those days when nothing else was available, or due to requirements using Microsoft Teams with on-premises mailboxes. The adoption of Modern Hybrid shows that the Hybrid Agent approach helps organizations that cannot implement a Classic Full Hybrid.
I leave the results of this questionnaire to your interpretation and look forward to your replies, either to this blog post or by social media on Twitter and LinkedIn. Please use the hashtag #ExchangeQuest2021.
There will be a new Exchange Server questionnaire in early 2022, covering various implementation scenarios in more detail. If you want to see a specific Exchange topic covered in the 2022 questionnaire, just let me know.
Again, thank you all for participating in this questionnaire.
You are not able to list public folders in a co-existence scenario with Exchange Server 2007 and Exchange Server 2010/2013 using the Exchange 2007 EMS or EMC.
When you try to execute Get-PublicFolder you receive the following error:
Get-PublicFolder " There is no existing PublicFolder that matches the following Identity: '\'. Please make sure that you specified the correct PublicFolder Identity and that you have the necessary permissions to view PublicFolder.
This might happen after you have removed the first Exchange 2007 mailbox server, but not the last Exchange 2007 mailbox server.
Exchange Server 2007 uses the Exchange System Attendant to access the public folder store and fails if the System Attendant discovery in Active Directory does not provide a proper configuration.
KB 2621350 describes the discovery process:
There two annoying things about these steps
The magic System Attendant mailbox has been removed from Exchange 2010. But the System Attendent configuration node does still exist in the Active Directory Configuration Partition for compatibility reasons. The configured attributes of the System Attendant entry vary depending on the version of the installed Exchange Server.
In regards to the public folder issue, we need to focus on the following:
To fix the public folder access issue for Exchange Server 2007, set the homeMDB and homeMTA attributes. Set the Exchange System Attendant attributes to appropriate values for your Exchange servers.
Repeat steps 4 to 8 for each Exchange 2013 server in your environment.
Repeat steps 4 to 13 for each Exchange 2010 server in your environment.
Wait for Active Directory replication and retry to access the public folders using Get-PublicFolder in an Exchange Server 2007 Management Shell.
It might be required to restart the Exchange 2007 Information Store and System Attendant service of the Exchange 2007 server in question
Use an administrative PowerShell
Restart-Service MSExchangeIS Restart-Service MSExchangeSA
I haven’t noticed any issues in production environments so far. If you encounter any issues in your environment, feel free to leave a comment.
Do you need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?
Contact me at thomas@mcsmemail.de Follow at https://twitter.com/stensitzki
The use of Exchange Edge Transport Servers requires the synchronization of user and configuration data from internal Exchange Servers to the Edge Transport Servers. The synchronization utilizes secure LDAP (EdgeSync) to transmit the data securely and is based on an Edge Subscription.
When you create a new Edge Subscription on your internal Exchange Servers by importing the Edge Subscription XML-file, establishing the EdgeSync-connection might fail.
You will find the following error in the application event log of the internal Exchange Server:
Log Name: Application Source: MSExchange EdgeSync Event ID: 1035 Task Category: Synchronization Level: Error Keywords: Classic Description: EdgeSync failed to synchronize because it only supports Cryptographic API certificates. The local Hub Transport server's default certificate with thumbprint XYZ isn't a CAPI certificate. To set a CAPI certificate as the default certificate, use the Enable-ExchangeCertificate cmdlet with the Services parameter using the value of SMTP.
The private key of the current Exchange Transport default certificate of the internal Exchange servers uses a CNG private key. EdgeSync requires a CAPI1 based private key.
This problem occurs primarily when using an Enterprise Certificate Authority using certificate templates with individual template settings.
Get-TransportService | ft Name,InternalTransportCertificateThumbprint
certutil -v -store my > cert.txt
If both attribute are of the value 0, the certificate if a CNG certificate.
The section might look like this:
Unique container name: XYZ Provider = Microsoft Software Key Storage Provider ProviderType = 0 Flags = 20 (32) CRYPT_MACHINE_KEYSET -- 20 (32) KeySpec = 0 -- XCN_AT_NONE
Use OpenSSL to convert the CNG certificate to a CAPI1 certificate.
Using OpenSSL requires the download of the Windows release of OpenSSL. I recommend to not install the software on the Exchange Server but a separate Windows server or your administrative desktop system. Additionally, you need the certificate with its private key as a PFX-file.
Use the following steps to convert the CNG certificate to a CAPI1 certificate.
openssl pkcs12 -in CERT.pfx -out cert.pem -nodes
openssl pkcs12 -export -in cert.pem -out NEWCERT.pfx
The new PFX-file is now a CAPI1 certificate. The new certificate has the same thumbprint. Now you must replace the current certificate used by Exchange Server with the new certificate.
Replacing the certificate requires a downtime of each Exchange Server requiring the certificate replacement. This is due to the requirement to remove the CNG certificate first, following the import of the CAPI1 certificate. Afterward, you need to enable the required Exchange services.
Get-ExchangeCertificate -Server SERVERNAME
# It is mandatory to answer the query for replacing the default certificate with YES Enable-ExchangeCertificate -Thumbprint THUMBPRINT -Services SMTP # Restart the transport service Restart-Service MSExchangeTransport
# It is mandatory to answer the query for replacing the default certificate with YES Enable-ExchangeCertificate -Thumbprint NEWCERTTHUMBPRINT -Services SMTP # Restart the transport service Restart-Service MSExchangeTransport
Now, that you updated the local Exchange Servers there is one more step that needs to be checked on the Edge Transport Servers.
Edge Transport Servers are not domain-joined and therefore do not receive any GPO-based configuration. Each required configuration must be performed locally. To ensure that the default transport certificate of the internal Exchange servers can be used for cryptographic operations we must ensure that the certificate chain of that certificate is present in the certificate store of Edge Transport servers.
Take a look at the certificate chain of the converted CAPI1 certificate and import the Root-CA and Subordinate-CA certificates into the Edge Transport servers local certificate store. You must ensure that the certificates are placed into appropriate stores:
Next, you create a new Edge Subscription on your Edge Transport server and create a new subscription for the Active Directory site on the internal Exchange Server. The internal Exchange Servers are now able to establish an EdgeSync connection and encrypting the data transferred to the Edge Transport servers.
When you receive the TLS certificate as PFX/PKCS12 file, you import the certificate and the private key. The import process itself defines the priavte key Crypto Provider. Using the following command line you ensure that the import process suses the legacy crypto provider.
certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx my MYCERTpfx
Enjoy Exchange Server and Edge Transport!
Are you located in Germany, Austria, or Switzerland? Join the Exchange User Group DACH to collaborate with other Exchange enthusiasts. Follow us on Twitter @exusg, join on Meetup, or visit our website.
The new community script Get-Diskspace helps to fetch disk volume information from a single server or across multiple servers.
Currently the script supports a command line switch to gather disk volume information across all Exchange servers in your environment.
The following screenshot shows the command line output
The following screenshot shows the html email
# Get disk information from computer MYSERVER .\Get-Diskpace.ps1 -ComputerName MYSERVER # Get disk information from computer MYSERVER in MB .\Get-Diskpace.ps1 -ComputerName MYSERVER -Unit MB # Get disk information from all Exchange servers and send html email .\Get-Diskpace.ps1 -AllExchangeServer -SendMail -MailFrom postmaster@sedna-inc.com -MailTo exchangeadmin@sedna-inc.com -MailServer mail.sedna-inc.com
Enjoy.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?
This script copies a single receive connector from a source Exchange Server to a single target Exchange server or all other Exchange servers.
The primary purposes of this script are:
Find the most recent full documentation at GitHub.
Copy Exchange 2013/2016 receive connector RC2 from server MBX01 to server MBX2
.\Copy-ReceiveConnector.ps1 -SourceServer MBX01 -ConnectorName RC2 ` -TargetServer MBX2 -DomainController MYDC1.mcsmemail.de
Copy Exchange 2013/2016 receive connector RC2 from server MBX01 to all other Exchange 2013 servers
.\Copy-ReceiveConnector.ps1 -SourceServer MBX01 -ConnectorName RC1 ` -CopyToAllOther -DomainController MYDC1.mcsmemail.de
Copy Exchange 2013/2016 receive connector relay from Exchange 2007 server MBX2007 to Exchange 2013 server MBX01 and reset network bindings
.\Copy-ReceiveConnector.ps1 -SourceServer MBX2007 -ConnectorName "relay" ` -TargetServer MBX01 -MoveToFrontend -ResetBindings ` -DomainController MYDC1.mcsmemail.de
Additional credits go to Jeffery Land, https://jefferyland.wordpress.com