The MSILOG indeed showed that the setup was looking for the RTM language files in the original location where the setup files were, but they are long gone… with the RTM DVD no where to be-found (RTM trial files + the oldest Language Pack bundle are in a non compatible version) this situation was doomed to failure.

So, I’ve turned to manually remove any references to the Client / Server language packs on the server, this included removing a whole bunch of registry keys:

And it works ! Now, I guess that with a script this would have been much quicker then the registry method, but at least now I’m (and you are) aware of this workaround , and here’s the script for your usage:

** edit the $setuplocation variable for your directory of the servicepack.

Following a troubleshooting session I’ve had lately, I wanted to share with you an important recommended settings that most folks (myself included) often overlook.

With more and more virtual servers and less and less physical servers being deployed, capabilities like SpeedStep of a CPU were forgotten. Take for example the following “modest” specifications of Intel Xeon E5-2690 v2, with 10 cores @ 3.0 GHz this is a “fare” spec for a high load / CPU intensive profile server.

BUT ! if you forget to select the “High Performance” power option in Windows Server for example, you could end up with:

Notice that the speed of the CPU is less the half the speed it can run at. now to make things better, just make sure to select the “preferred” settings for your busy server:

Just a heads up for all you folks out there, the default “Balanced” option caused a performance issue with an Exchange 2013 server that was running on this physical hardware and once the option was changed – all was back to normal 🙂

This article describes a hotfix rollup for Windows 7 Service Pack 1 (SP1)-based and Windows Server 2008 R2 SP1-based computers. This hotfix rollup contains 90 hotfixes that were released after the release of SP1 for Windows 7 and Windows Server 2008 R2. These hotfixes improve the overall performance and system reliability of Windows 7 SP1-based and Windows Server 2008 R2 SP1-based computers. We recommend that you apply this hotfix rollup as part of your regular maintenance routine and build processes for Windows 7 and Windows Server 2008 R2 computers.Note This hotfix rollup primarily addresses the issues that occur on domain-joined client computers and servers. Therefore, this hotfix rollup is available only from the Microsoft Update Catalog. You can also install this hotfix rollup on computers that are running Windows 7 SP1 in nonenterprise environments. After you install the hotfix rollup, the performance of the computers may be improved.

Update 9/Jun/2015 – Thanks to Josh Davis for the feedback, I’ve added a note about making sure to include both drives (if EDB and LOG files are separated).

Update 21/Oct/2013 – This article suggests that you cannot sustain downtime or interruption for your users while battling with deleting log files or restoring your working backup solution. If you can sustain a downtime (should be around minutes or so) the easiest method will be to enable Circular Logging on your database / storage group – see more here – http://technet.microsoft.com/en-us/library/bb331958%28v=exchg.141%29.aspx#UTL

I often get calls and questions regarding backups and Exchange Server, since ever this issue is not always working as required or as you would expect, but that’s off-topic 🙂

One of the most common stories is that without a working Exchange Server backup when you perform massive mailbox moves, transaction logs will get piled and fill up the volume or disk that they reside in. and then panic starts, “hey my databases were dismounted…” then of course the administrator realizes that the space on the log drive or volume has indeed ran out and now he needs to figure out what to delete.. and here’s where this post comes in…

So how can you delete or purge Exchange server logs without any risk ? well, in simple – you cannot, because the whole idea of restoring an Exchange or for this matter any transactional database requires you to have a first – “full” backup of the database itself and all transaction logs that were generated since the the date of the database creation date, or the last “successful” “full backup”.

Now here’s a nice method to “fake” a “full backup” or an on-demand transaction logs purge when you see you will be soon out of space, using the Exchange VSS writers and the diskshadow utility (available with Server 2008 or 2008 R2) . This procedure also “proves” that a VSS backup for your Exchange Server will work fine.

note: This method was tested on an Exchange server with Locally Attached Disks, not storage attached LUNs.

Use this method on on your risk. You should preform a “Full Backup” right after this process is done.

This example will show you how to purge the logs for a database that is located on Drive D, the log files of the databases are also located in Drive D. we will “fake backup” drive D and this will trigger the logs to be purged.

Note: If you have separated your log files and database file in different drives, or you want to include additional databases in the “backup” you must include the additional drives in the process, so in the example below, you will “Add volume e:” after “Add volume drive d:” and so on…

Open Command prompt

Launch Diskshadow

Add volume d:

(optional, add one line for each additional drive to include) Add volume X:

Begin Backup

Create

End Backup

At this step you should notice the following events in the application log indicating that the backup was indeed successful and logs will now be deleted.

Here’s some screenshots from the process:

The Diskshadow example screenshot.

ESE – Event ID 2005 – Starting a Full Shadow Copy Backup

MSexchangeIS – Exchange VSS Writer preparation.

ESE Event ID 224 – Logs are now purged 🙂

MSExchangeIS Event ID 9780 – Backup is now complete.

side note: although this example was tested against Exchange 2010, it should work just as fine with Exchange 2013 & 2007.

I was asked today to add a permission to the Exchange Auditing log which is included with Exchange 2007 SP2 installations to simplify auditing,
after activating Mailbox Access Auditing , I was requested to allow read only permissions to the IT Security group.

What seemed to be quite straight forward, was soon to be changed with SDDL ACL format….

Here’s the quick how-to:

– Note, this was done on a Windows 2008 server

Identify the SID of the user/group you wish to allow access.
Using powershell you can easily find it e.g:
Get-User | Select SID
Get-Group | Select SID

Then following this KB – Which was the most simple and self-explained, add the appropriate permissions. http://support.microsoft.com/kb/2028427In-Short – each event log is located in the registry at: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLog
the Exchange Auditing log is also located there, and in that key you will find an existing CustomSD string value with the ACL’s in the SDDL format ( more info in the links I added below )
I was required to add read-only permissions to the IT Audit group, which is a “regular” group, without special domain / enterprise rights,
so in my case i used the following:
(A;;0x1;;; [Your Group Name/user account SID])
so appended that to the existing CustomSD value.

Restart the server.

Now the user/group can access the Exchange Auditing log from any computer 🙂

A comment from Scott Landry gave a new solution for this, and seems it’s now also been related to Hyper-V, as the suggested KB http://support.microsoft.com/kb/980050 – Error message when the Exchange Server 2010 setup on a Hyper-V virtual machine fails:“2147504141”

Anyhow, disabling the ” Time synchronization ” from the Integration Services settings on the Virtual Machine solved this !

Event ID : 2147
Raw Event ID : 2147
Source : MSExchangeRepl
Type : Error
Machine : SERVER
Message : There was a problem with ‘ActiveNode’, which is an alternate name for ‘ActiveNode’. The list of aliases is now ‘ActiveNode’, and the alias ‘was’ removed from the list. The specific problem is ‘CreateFile(\ActiveNodeStorageGroupGuid$LogFile.log) = 2′.

ID: 2127
Level: Information
Provider: MSExchangeRepl
Machine: SERVER
Message: The system has detected a change in the available replication networks. The system is now using network ‘ActiveNode’ instead of network ‘ActiveNode’ for log copying from node ActiveNode.

Thanks a lot for JR on sharing this, check out Tim McMichael with more info on this: