When you move your DotNetNuke 7 instance from Windows Server 2012 to a new Windows Server 2012 R2 instance you might end up with a not properly rendered skin. This issue relates to a situation where the releated Telerik Script Manager is not properly loaded.
Querying the affected website with Web Page Test showed in this case that the query for the Telerik.Web.UI.WebResource.axd resource resulted in an 404 http error.
Searching the web resulted in a variation of proposed solutions to this issue. In this case the solution is as follows.
The Telerik.Web.UI.WebResource.axd handler requires to be added to the system.webServer/handlers section of the web.config.
<handlers> <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" /> <add name="Telerik.Web.UI.WebResource" path="Telerik.Web.UI.WebResource.axd" verb="*" type="Telerik.Web.UI.WebResource, Telerik.Web.UI, Culture=neutral, PublicKeyToken=121fae78165ba3d4" /> </handlers>
If the system.webServer node does not have a handlers node, just add it.
When you use Symantec NetBackup 7.x you might encounter Error 5, when you try to restore an Exchange Server 2013 DAG mailbox database backup to a Recovery database or to the original datrabase.
The error message in Backup, Archive, and Restore Tool looks similar to this
Enabling NetBackup debug logging by using the mklogdir.bat file located in C:\Program Files\Veritas\NetBackup\logs does not necessarily provide additional input. The restore job fails before entering the job section for local restore activities. So no TAR log is being created.
When following the NetBackup Admin Guide and several Symantec HowTo’s you have already configured the following two services to run using a dedicated Service Account
There are some circumstances (not clearly defined by Symantec) when an additional NetBackup Service performs Exchange PowerShell commands as part of a restore process. Therefore the following NetBackup service must be configured to run using the same Service Account as the other two NetBackup services.
In addition be aware that the Service Account required Debug permission on the Exchange Server. It might be helpful to propagate the permissions for the Service Account using a GPO.
Sometimes you have the need to download the Offline Addressbook (OAB) for the Outlook email client manually.
When initiating a manual OAB download you might encounter a 0x80200051 error. A common mitigation scenario is to switch between Outlook Online-Mode and Outlook Cached-Mode multiple times. This mitigation scenario does not solve the issue.
When you active Outlook Cached-Mode it is required to perform a full OAB download. The OAB download dialogue provides an option to download OAB changes only. This option ist selected by default. To start a full OAB download you must deselect the checkbox.
Using this download setting you will not encounter the mentioned error and the Offline Addressbook is downloaded by your Outlook email client sucessfully.
Enjoy Outlook!
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.
You might encounter a situation when the MSExchangeSA service is stopped and you are not able to start the service.
When you try to start the service the follow event log error is logged:
Log Name: Application Source: MSExchangeSA Date: 08.01.2016 09:40:33 Event ID: 1005 Task Category: General Level: Error Keywords: Classic User: N/A Computer: SERVER01.MCSMEMAIL.DE Description: Unexpected error Access is denied. Facility: Win32 ID no: c0070005 Microsoft Exchange System Attendant occurred.
This issue happens most likely due to an endpoint protection solution (aka AV Scanner) blocking access to the MSExchangeSA executable.
The simple apporach to get the service running is to restart the server.
If you need to run local endpoint protection on your Exchange servers, keep in mind to configure the appropriate scan exclusions:
When you install the Exchange Server Security Update KB 3087126 on a server running the Exchange Server 2013 management tools only, you might receive an error message when starting the Exchange Management Shell.
The error might look like this:
The error message indicates that WinRM is having issues.This is not the case.
The problem occues due to registry changes performed by the patch setup and due to the way how ConnectFunctions.ps1 (used by RemoteExchange.ps1) determines the Exchange Server to connect to.
The script tries to connect to the local FQDN, if any Exchange role is installed on the local server. This is determined by querying the registry using the following command:
if (@(get-item HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\*role -erroraction:silentlycontinue).length -gt 0)
The queried registry does not exist prior to installation of KB 3087126.
When having installed the Exchange Server 2013 management tools only, which might be the case on a monitoring or scheduled task server, do the following:
Enjoy the Exchange Management Shell.
Mailscape 365 - Hybrid Exchange & Office 365 Monitoring and Reporting Many organizations are choosing to use a mix of on-premise Microsoft Exchange and hosted Office 365 to meet their staff needs. These deployments, however, are challenging to support, with several 'moving parts' that need to be monitored in order to ensure reliable messaging and calendaring services - Test Drive Mailscape for Exchange Online
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”