My Technet Subscription only gives me access to a Retail version of Microsoft Office 15. So no, Office Customization Tool. Running setup.exe /admin confirmed that with the error message: 

Files necessary to run the Office Customization Tool were not found. Run Setup from the installation point of a qualifying product.

However, you can easily fix this by downloading the Office 2013 Administrative Template files (ADMX/ADML) and Office Customization Tool. Run the executable and let it extract to a temporary location.

Copy the admin folder to the installation source of Office 2013 and setup.exe /admin will start the Office Customization Tool.

Found a great resource today that lists all the exceptions that Microsoft advises to configure when running Virus Scan Software on Forefront Threat Management Gateway.

In general I have the feeling that fine tuning the Virus Scan Exception policy is something that is not or hardly done. In most cases the products function correct, but a large performance penalty might be introduced that is not needed. If a few exception rules are configured, a lot of wasted resources can be won back.

While working on the configuration of my TMG Server I observed inconsistent behavior and slow system performance. After a quick investigation I noticed a number of log entries after a system reboot in the Event Log.

The entries came from MSSQL$MSFW with Event IDs 17204 and 17207. Additionally I noticed that the Default Log Queue location of TMG (C:\Program Files\Microsoft Threat Management Gateway\Logs) was filled up with more then 650.000 files consuming 14 GBytes of system disk space.

Root Cause

The problem is that for some reason one or more databases had become corrupt and prevented SQL Server from correctly starting up and processing log entries from TMG. Therefore Forefront TMG falls back to its Log Queue.

Since the issue was already going on for some time in my case, I could not establish the root cause that caused the Database files to corrupt in the first place. But I do recall a BSOD from some time ago on the host OS due to a driver issue. That probably caused the issue.

Remove Corrupt Databases

I found a solution on the Microsoft Forums that describes how to remove the corrupt databases from Microsoft SQL Server in order to get SQL Server back in business.

1. Start an command prompt and connect to the SQL Server database with the SQL Server Command Line Tool: OSQL -S %TMGComputerName%\msfw -E
2. Delete each corrupt database with the following command: DROP DATABASE %DATABSENAME%
3. Execute the commands by entering the command GO.
4. Restart the SQL Server service for the SQL Server Instance msfw.
5. Verify in the Event Log that no new corrupt databases are logged, if so repeat steps  1 to 4 until no events 117204 and 11207 are logged.

Log Queue

Once the SQL Server becomes available, the Log Queue should start processing again and write all queued up entries to the SQL Database. This can be monitored from the Management Console.

In my case it took a couple of hours due to the size.

TMG Log Queue Status

I like time to be on time and manually configure the NTP server for my domain. This way I can choose a time source which I have good connectivity to. But Kerberos needs the time to be synced within the domain or authentication will fail.

To configure a manual time source take the following steps:

1. Choose a NTP Server as Source
2. Find the PDC emulator
3. Stop the Time Service
4. Configure the Time Provider
5. Open any firewall ports
6. Start the Time Service
7. Verify result

Choose NTP Server as Source

For me the Time Servers from xs4all are the best. But one good place to start is pool.ntp.org.

I’ll just stick to ntp.xs4all.nl and ntp2.xs4all.nl

Find the PDC Emulator

To find the PDC there are multiple options, from old to new:

• netdom /query fsmo (Technet Background Info)
• dsquery server -hasfsmo pdc (Technet Background Info)
• Get-ADDomainController -Discover -Service PrimaryDC (Technet Background Info)

Stop the Time Service

Well, here again multiple possibilities. But let’s just stick to PowerShell:

Stop-Service W32Time

Configure the Time Provider

w32tm /config /syncfromflags:manual /manualpeerlist:”0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org”

Since the time is configured on the PDC there is no need to set it as a reliable source.

Open Firewall Ports

The NTP protocol uses UDP on port 123. See RCF 1305

Start the Time Service

Start-Service W32Time

Verify the Result

With the following command the configuration can be verified:

w32tm /query /configuration

To perform a sync:

w32tm /resync

This should respond with a message saying: The command completed successfully.

To check on the status:

w32tm /query /status

For the first time in my life I saw S.M.A.R.T. in action. Both the BIOS and Windows reported that an issue was detected with a hard disk and that failure could occur.

The Windows Event log didn’t show any hard disk read errors yet, so cloning the disk would have a high chance of success.

I’ve seen disks fail all the time, so nothing new there. But I’ve never seen the S.M.A.R.T. system warn up-front so a replacement is possible without losing any data.

So I added a new disk, did a clone of the drive. Updated the MBR on the new disk, removed the old disk, update BIOS and good to go with a new drive. No unexpected down time, or even worse… data loss.

I didn’t take the time to look what exact S.M.A.R.T. parameter triggered the error.

For the installation of Forefront TMG I slipstreamed the updates which saves a lot of time. For Forefront UAG it is even more interesting to slipstream the updates. Since both Forefront TMG and Forefront UAG have a set of updates that need to be applied.

When searching for a tutorial I only found a post on the Microsoft Forum regarding the slipstreaming the updates for Forefront UAG. However, no one is reporting any results good nor bad.

Continue reading →