This scripts helps to suspend all messages in an Exchange transport queue and to export all suspended messages to a given target folder.
The script uses the AssembleMessage cmdlet to properly export queued messages as .eml files.
Optionally, all exported messages can be removed from the transport queue.
This script requires the GlobalFunctions module for logging.
# EXAMPLE 1 # Export messages from queue MCMEP01\45534 to D:\ExportedMessages and do not delete messages after export .\Export-MessageQueue -Queue MCMEP01\45534 -Path D:\ExportedMessages # EXAMPLE 2 # Export messages from queue MCMEP01\45534 to D:\ExportedMessages and delete messages after export .\Export-MessageQueue -Queue MCMEP01\45534 -Path D:\ExportedMessages -DeleteAfterExport
As always: Test and familiarize yourself with the script in a test or development environment.
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.
Exchange email adress policies are used to generate addresses since the early days of Exchange. Email address policies are used to automatically generate addresses for various protocols (SMTP, FAX, CCMAIL, MSMAIL). These overall use of address policies is well documented, but there is still some odd behaviour of the policies when it comes to language specific character handling.
The following list describes the common parameters:
All language specific characters and other non RFC 821/822 compliant characters are either translated or removed.
User without any language specific characters
Given Name: John Last Name : Doe Alias : JohnDoe
Email address policy results
%g.%s@mcsmemail.de = John.Doe@mcsmemail.de %m@mcsmemail.de = JohnDoe@mcsmemail.de %1g_%s@mcsmemail.de = J_Doe@mcsmemail.de
User with German language specific characters
Given Name: Michael Last Name : Müller Alias : Michael Mueller
%g.%s@mcsmemail.de = Michael.Mueller@mcsmemail.de %m@mcsmemail.de = Michael-Mueller@mcsmemail.de %2g%s@mcsmemail.de = MiMueller@mcsmemail.de
User with Scottish language specific characters
Given Name: Ian Last Name : O'Connell Alias : IanOConnell
%g.%s@mcsmemail.de = Ian.O'Connell@mcsmemail.de %m@mcsmemail.de = IanOConnell@mcsmemail.de %3g%5s@mcsmemail.de = IanO'Con@mcsmemail.de
As you might have noticed, the apostrophe is not handled as a special character but an RFC compliant character. The address policy is applied without any issues at all.
But a SMTP address containing an apostrophe leads to email transport errors and must be removed.
You can use the replacement parameter to strip all apostrophes from the surname by using the following email address policy.
%g.%r''%s@mcsmemail.de = Ian.OConnell@mcsmemail.de
This example will only remove apostrophes from the surname (%s) as the replacement parameter is placed in front of the surname parameter.
You might encounter EventId 106 errors on Exchange 2013/2016 servers.
There are some article available on how to fix this issue on servers having a full installationof Exchange Server 2013/2016.
But you might encounter this error on servers having the Exchange 2013/2016 Management Tools installed only as well. In this case the solutions described will not work as expected.
Running the New-PerfCounters cmdlet requires the Microsoft.Exchange.Management.PowerShell.Setup PowerShell snapin. This PowerShell snapin cannot be loaded on servers having the Exchange Management Tools installed.
Add-PsSnapin : The Windows PowerShell snap-in 'Microsoft.Exchange.Management.PowerShell.Setup' is not installed on this computer. At line:1 char:1 + Add-PsSnapin Microsoft.Exchange.Management.PowerShell.Setup + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (Microsoft.Excha...owerShell.Setup:String) [Add-PSSnapin], PSArgumentEx ception + FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
The required code library is available on servers having the Exchange Management Tools installed. But the library is not added to the registry by default.
Registry of a server running Exchange Management Tools only:
Registry of a fully installed Exchange Server:
Just export the registry key Microsoft.Exchange.Management.PowerShell.Setup from an Exchange Server, fix Exchange file paths (if required) and import the regiytry file on the server having the Exchange Management Tools installed.
Example registry file:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.Setup] "CustomPSSnapInType"="Microsoft.Exchange.Management.PowerShell.SetupPSSnapIn" "ApplicationBase"="D:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin" "AssemblyName"="Microsoft.Exchange.PowerShell.Configuration, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" "Description"="Setup Tasks for the Exchange Server" "ModuleName"="D:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin\\Microsoft.Exchange.PowerShell.configuration.dll" "PowerShellVersion"="1.0" "Vendor"="Microsoft" "Version"="15.0.0.0"
After adding the registry key, you can successfully fix the performance counter issue.
Add-PsSnapin Microsoft.Exchange.Management.PowerShell.Setup New-PerfCounters -DefinitionFileName "$exinstall\setup\perf\WorkerTaskFrameworkPerfCounters.xml”
In some scenarions the current Exchange cumulative updates (Exchange 2013 CU14, Exchange 2016 CU3) resulted in failed and corrupted search indices.
In Exchange Server 2013 the failed search service resulted in the following event log message:
Watson report about to be sent for process id: 28160, with parameters: E12IIS, c-RTL-AMD64, 15.00.1236.003, M.E.Search.Service, M.E.Data.Directory, M.E.D.D.ScopeSet.GetOrgWideDefaultScopeSet, System.ArgumentNullException, 301, 15.00.1236.000. ErrorReportingEnabled: False
A community post states that there won't be an interim hotfix.
But at least the issue has been found and will be fixed with the next cumulative updates for Exchange Server 2013 and Exchange Server 2016.