When you run setup to upgrade Exchange server 2013, it checks prerequisites and one of its actions is to contact Active Directory to check schema version for possible need to update. In my case the problem was, that error 0x51 occured. I was checking what is happening. The first thing was to run netdom query fsmo command to gather which FSMO roles were placed on failing DC1. As it was during Schema version check, I was mostly iterested if Schema master role is present there…. and it was, No I was wondering what is the problem. I went to OU=Domain controllers in ADUC and checked DCs. I realised that Schema master role is running on non GC domain controller.
Solution: To run setup successfully seize FSMO Schema master role on DC with GC in the same AD site as Exchange server.
I have faced a problem with net-Framework-core package installation. As you probably know, this package is deprecated, but still available, when you specify source. It can be installed by command
Add-WindowsFeature net-Framework-core -Sources <path to Windows Server 2012 installation media>\Sources\SxS
If that doesnt work, you should check several things:
- Is the installation media from the same build as current OS (should be)
- Isnt it corrupted
- Sometimes it is helpful to map installation media on another server and use UNC path instead of local
- In my case problem was in Windows Update Services setting. The registry key stated, no automatic update is possible and WUS is used for updates.
Solution: Locate registry key below, change value to “0” and install net Framework core feature. After done, change back to “1” – if still no go, change value to 0 and reboot server prior to install.
An ExRAAP scanning detected this issue “The read I/O operations latency is greater than expected for an Exchange database” with an advice I started to monitor related performance counters according to post Analysing Exchange Server 2010 Jetstress BLG Files By Hand which contains also the following table:
Time to time I needed to check read I/O operations without a Data Collector Set, but I did not want to have the counter list/settings dependent on particular server (i.e. the server below hosts mailbox database MDB01 or MDB05 but not MDB02 and I want to have counters for all of them and I do not mind that some counter will not work).
Well, I saved the settings from the server into HTML file and modify its content for 18 databases.
- Changing value: <PARAM NAME=”CounterCount” VALUE=”18″/>
- Adding parameters for missing databases (be careful you have to always use unique PARAM NAME):After that I could check the latency by pasting the same counter list on any server.
You can use administrator audit logging in Microsoft Exchange Server to record actions taken by a user or administrator that make changes in your organization. By keeping a log of the changes, you can trace a change to the person who made it. You can also augment your change logs with detailed records of the change as it was implemented, use the records to comply with regulatory requirements and requests for discovery, and so on…. [source].
Yes, yes, the auditing is very useful. But I wanted to show you how could look a cmdlet statistic for a month:
PS C:\> Search-AdminAuditLog -StartDate $(get-date).addMonths(-1) -ResultSize 100000 -IsSuccess $true|select CmdletName|
group CmdletName|sort count -Descending|ft count,name -a
Note: Cmdlets that begin with the verb Test, Get and Search aren’t logged by default.