You might encounter a situation where you log on to your Windows 10 client and the Start menu is unresponsive and the taskbar remains empty.
The following two actions help to recover from the situation.
Open an administrative PowerShell window and execute the following command
DISM /Online /Cleanup-Image /RestoreHealth
Restart Windows and check if the issue has been fixed.
Reinstall (fix) all Windows apps. This step requires internet access, as all sources are downloaded using the local app manifest information
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Be patient and wait until the app download and installation process has been completed. Just ignore any error message and restart Windows.
The first step might fix the issue already. if this is the case, do not execute the PowerShell cmdlet described in step 2.
The other day I came across the famous "Windows Installer reconfigured the product X" error. I am going to name it an error even if the event log entry is catagorized as informational.
Windows Installer reconfigured the product. Product Name: [PRODUCT NAME]. Product Version: [VERSION]. Product Language: [LOCALE ID]. Manufacturer: [MANUFACTURER]. Reconfiguration success or error status: 0.
In preparation for an Exchange Server 2013 setup I was wondering that Event Id 1035 was logged every 4 hours. The MsiInstaller itself got triggered by the Systems Account, which is pretty normal. By using Windows Performance Recorder (WPR) and Windows Performance Analyzer (WPA) I was able to identify that the MsiInstaller was triggered when a PowerShell script got executed.
Note: WPR and WPA are part of the Windowas ADK (see Links section)
It turned out that the PowerShell script itself was part of a Nagios-style monitoring solution and was executed as part of a plug-in. The system monitoring was part of the base template of the virtual machine.
But why would a PowerShell script trigger MsiInstaller?
The script was using a Get-WmiObject query to fetch an inventory of installed software on the server.
To quote Ed Wilson (The Scripting Guy):
"This would not a terrible thing to do in your dev or test environment. However, I would not recommend querying Win32_Product in your production environment unless you are in a maintenance window."
Think of running such a query on an Exchange Server 2013 in production environment (which I did just for the sake of it) triggers the "reconfiguration" of all installed software on the server. The number of generated event log entries will drive you (as an Administrator) crazy.
If you are in need to get an inventory of the installed software on server, do not use the Win32_Product class.
Instead follow the advice given by Ed Wilson to query the Windows Registry and fetch the data provided under
HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
PowerShell Query:
Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Format-Table –AutoSize
Enjoy.
Services of third-party software solutions often interfere with installing a new Exchange Server cumulative update, because these services have a file lock active.
To avoid any issues when installing a CU, or having the prerequisites check fail due to open files, you simply stop the Windows services and ensure that those services do not restart automatically. Especially monitoring solutions that use some kind of watchdog service are a candidate that you must disable for installing an Exchange Server CU.
The following two PowerShell examples help you to prepare the Windows services for installing an Exchange Server CU.
In preparation for the installation of an Exchange Server cumulative update, you can use the following PowerShell commands.
# Disable and stop services or just stop services # Add other services as needed # Set SMEX service to manual and stop services Get-Service -Name 'ScanMail*' | Set-Service -StartupType Manual Get-Service -Name 'ScanMail*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force # Stop SMEX SQL Express instance Get-Service -Name 'MSSQL*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force # Disable and stop ENow monitoring services Get-Service 'ENow*' | Set-Service -StartupType Disabled Get-Service 'ENow*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force # Stop NetBackup service Get-Service -Name 'NetBackup*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force
After installing the Exchange Server cumulative update you should restart your computer. I recommend initiating a check for additional Windows Updates for the CU. This helps to ensure that you do not only have the latest CU installed, but required security updates as well.
# Enabling and starting services # Adjust the list of services as needed # Enable and start SMEX services Get-Service -Name 'ScanMail*' | Set-Service -StartupType Automatic Get-Service -Name 'ScanMail*' | Start-Service # Enable and start ENow Monitoring services Get-Service -Name 'ENow*' | Set-Service -StartupType Automatic Get-Service -Name 'ENow*' | Start-Service
Enjoy Exchange Server.
Changes to AutoDiscover settings in Exchange are cached by each AutoD IIS application for approximately 2 hours. If you want to have configuration changes available quickly, it required to restart the AutoD application pool on each Client Access Server serving AutoD request. Additionally you have top restart the MSExchangeServiceHost process as well.
You can use the following PowerShell code to restart the application pool and the MSExchangeServerHost process across all Exchange 2013 servers.
Restart Application Pool
Get-ExchangeServer | ? { $_.AdminDisplayVersion -like '*15.*'} | % { Invoke-Command -ComputerName $_.Name -ScriptBlock {Restart-WebAppPool MSExchangeAutodiscoverAppPool } }
Restart MSExchangeServiceHost
Get-ExchangeServer | ? { $_.AdminDisplayVersion -like '*15.*'} | % { Invoke-Command -ComputerName $_.Name -ScriptBlock {Restart-Service MSExchangeServiceHost } }
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
When you maintain a number of servers which require to trigger the same scheduled task manually, you can simplify 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 Administrator" in Shortcut -> Advanced settings.
This post has been published originally on my legacy blog SF-Tools.
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.
Sometimes you need to know the version of the installed .NET Framework version quickly.
Simply use the following PowerShell one-liner:
(Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' ).Release
Enjoy!