Exchange 2013 mail stuck in draft - Mailbox Transport Submission service failing to start

We just recently begun building an Exchange 2013 DAG to support out email environment. This is part of an internal shift to Lync 2013 and Exchange 2013 for unified communications. We followed Microsoft instructions on building my first 2013 machine, migrated a single test mailbox and started testing.

We found no mail flow between the Exchange 2013 and Exchange 2010 environments, all email sent from 2013 OWA or Outlook was just sitting in the drafts folder. In fact even if I emailed within mailboxes on the 2013 mail database they would also stay in drafts.

Upon investigating this problem there was a failure of the "Microsoft Exchange Mailbox Transport Submission", "Microsoft Exchange Transport" and "Microsoft Exchange Frontend Transport" services.



The Problem

Windows application event logs showed the following errors when trying to restart the "Microsoft Exchange Mailbox Transport Submission" service.

Log Name: Application
Source: Application Error
Event ID: 1000 

Faulting application name: MSExchangeSubmission.exe, version: 15.0.712.12, time stamp: 0x51aff4c9
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc00000fd
Fault offset: 0x000007fb0b3cc301
Faulting process id: 0x2894
Faulting application start time: 0x01ceaa8fd8cefada
Faulting application path: C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeSubmission.exe
Faulting module path: unknown
Report Id: 179beb57-1683-11e3-93f5-00155dd80a77
Faulting package full name:
Faulting package-relative application ID: 

There is also another event log with some more telling information.

Log Name: Application
Source: MSExchangeTransportSubmission
Event ID: 7010 

The activation of modules are taking longer than expected to complete. Current state of components:<LoadTimings>
....
  <Component Name="Dns" Elapsed="00:00:23.1781923" IsRunning="true" />
</LoadTimings>
<StartTimings />
<StopTimings />
<UnloadTimings />

It is indicating that the DNS component was failing to start in a timely manner.



The Resolution

We checked and double checked our DNS, no issues. We also followed a number of blogs that indicate you need disable IPv6 and manually select the network adapter under DNS lookups on the Exchange server properties. We did this to no avail, however the actual resolution wasn't far off.

1. Open Exchange 2013 ECP
2. Go to "Servers" tab
3. Select "servers" from across the top menu
4. Double click the problematic server from the list of Exchange servers
5. Select "DNS lookups"
6. Instead of selecting your network adapter, select "Custom settings" under "External DNS lookups"
7. Add all your DNS servers
8. Repeat the same for "Internal DNS lookups"
9. Restart the above failing transport services
10. Rejoice

This seems to be a bug with a .NET 4 module Microsoft.Exchange.Net.ni.dll. Selecting "Custom settings" bypasses this .NET bug.

If you are still having issues with mail flow, ensure your new Exchange 2013 server has a system mailbox and consider removing the Exchange 2013 server, wiping AD clean and starting a fresh install.

eVc I2C PWM controller

I recently received an exciting package in the mail, Jon Elmor Sandstrom sent me his latest creation, eVc. eVc is a USB connected I2C controller, capable of interfacing directly with PWM controllers that support I2C. In short this device gives the ability to change a number of PWM settings on the fly. This can help to push insane overclockers and troubleshoot problems with motherboards and graphics cards.

I have taken a closer look at eVc with a Gigabyte 7790 OC card, first with ambient air cooling and then with -40 degree Celsius on my single stage cooler.

The video below goes into detailing explaining how eVc works with a little demonstration of the clocks gained by a combination of extra voltage, load line and subzero cooling.

I am really looking forward to seeing how the future of this device pans out.

James Trevaskis and G.Skill break the memory frequency world record with 4404 MHz

Since the launch of Z87 and Haswell there has been a big focus on memory clocking. We first saw memory frequency taken past the 4000 MHz mark by Gigabyte pre-launch. The record then bounced back and forward between Gigabyte, ASROCK and ASUS over the the last few months.

I decided to give the record a crack with the petite ASUS Maximus 6 Impact board and GSKILL 3000 MHz MFR kit and came up with some good numbers


Setup
ASUS Maximus 6 Impact
GSKILL 3000 MHz TridentX
Intel 4770K CPU
Corsair AX1200
Kingpincooling ram heatspreaders from Ney Pro and custom dominance copper pot
Liquid Nitrogen Cooling

The end result was a validated clock of 4404 MHz, smashing the current world record by over 100 MHz. Normally ram world records are decided by 5-10 MHz so this was a big achievement by the pint sized Impact.

Most overclocking records are respected within the OC community but ignored in the wider tech community, however this record gained widespread attention from the tech world. Here is a link to the ASUS ROG post about the record http://rog.asus.com/258552013/overclocking/4404mhz-ddr3-world-record/

Furthermore I was able to run SuperPI 1M, a very light stability test, past the current world record at around ~4300MHz.

Below are links to some of the Tech media that covered the record.
http://hexus.net/tech/news/ram/58797-gskill-reclaims-worlds-fastest-ddr3-memory-title-44ghz/
http://techgage.com/news/teamaus-youngpro-achieves-crazy-ddr3-4400-overclock-with-g-skill-tridentx-memory/
http://benchmarkreviews.com/3822/g-skill-tridentx-ddr3-overclocked-by-youngpro-to-4400mhz-with-ln2/
http://www.legitreviews.com/g-skill-tridentx-ddr3-memory-reaches-4400mhz-new-world-record_15854

Windows 8 networks drives not mapping via logon script with UAC enabled

Many enterprises attempting to tackle Windows 8 may find themselves in the same predicament we did, whereby existing logon scripts fail to map network drives when UAC is enabled. Unfortunately this isn't as simple to fix as it was in Windows 8, well that isn't strictly true, it is easy to fix by disabling UAC, but you introduce another problem, metro apps no longer work.

For those uninitiated, metro apps require UAC enabled to work, and in most circumstances UAC breaks drive mappings.

The root cause of this problem is that drive mappings are occurring in the under the wrong permission token.

When UAC is enabled, metro apps work, but drives are mapped with the privileged token, so you can't see them under windows explorer but if you open a command prompt as administrator you will be able to access those mapped drives.

When UAC is disabled, metro apps don't work, drives are still mapped with the privileged token but windows explorer is also started with the privileged token, so the mapping are visible.

The trick is being able to leave UAC enabled so metro apps work, but still mapping the network drives in the non-privileged context so they appear in explorer. Chances are if you have a complex logon script with HKCU registry edits, you probably want some of your logon script to run as privileged user (registry) and some as non-privileged user (drive mappings).

We tested a number of solutions that all had some downfalls:

• Disabling UAC and forfeiting the use of metro apps
• Playing around with different combinations of UAC group policy options
• Using the EnableLUA registry setting

None of the above could deliver mapped drives and working metro apps, however there is a solution.

The Solution

We use Kixtart scripting internally, so ideally we would like to keep these scripts when moving to Windows 8. I stumbled upon a function called RunAsInteractiveUser that was designed for Vista and Windows 7. The RunAsInteractiveUser function leverages windows task schedulers ability to run a task as the interactive user, therefor inheriting the unprivileged token if UAC is enabled.

This function allows programs to be launched as the non-privileged user when being launched from a privileged process on a system where UAC is enabled. 

We did a simple modification to our Kixtart script, when a Windows 8 system launches the logon script, the drive mapping section is ignored but is spawned with the non-privileged account. The code goes something like this.

;**** Windows 8 override/skips
if instr(@producttype,"Windows 8")
 ;if UAC is specified, only remap drives, skip rest of script
  if ($input = "uac")
    goto remap
  endif
  $RC=RunAsInteractiveUser("\\contoso.info\dfs\scripts\logon\logonuac.cmd", "", "c:\windows\temp\",1)
  ;exit
endif

We then use a batch file called logonuac.cmd to relaunch the logon script with a $input=uac argument, when this argument is specified the script only remaps the network drives and ignores the rest of the script.

1. GPO triggers user logon script with privileged token.
2. Logon script runs, if Windows 8 is detected it performs all actions with privileged token but skips drive mappings. The logon script is then relaunched with the $script=uac argument under the non-privileged token.
3. Logon script detects $script=uac and only maps network drives. After network drives are mapped, the logon script exits.

If you wanted to simplify you could move the drive mappings out of the main logon script into a separate script and use code something like.

if instr(@producttype,"Windows 8")
  $RC=RunAsInteractiveUser("\\contoso.info\scripts\logon\logonuac.cmd", ", "c:\windows\temp\",1)
else
    RUN '"\\contoso.info\scripts\logon\logonuac.cmd"
endif

This would map drives under Windows 8 systems with the privileged token and everything else as normal.

We spent days on this problem, hopefully this solution saves you time.

Alternatively if you are not running Kixtart and don't want to, you can look at the LaunchApp workaround script. You could also do something as simple as moving the logon script away from GPO and running it as a scheduled task on the local machine running as interactive user, this should also work.

Recovering corrupt Adobe Flash CS6 FLA files

Adobe Flash CS6 is an application widely used in both in secondary and tertiary design classes. However Adobe doesn't support saving files to the network, in fact they don't even support installing CS6 on domain joined computers. This is short sighted of Adobe, surely a large component of their CS business is driven by education sales, all of which would implement some form of domain or networked environment. After having continued errors with saving Photoshop and Flash files to the network we implemented a policy stating that users should save to the local drive then backup to the network.

Flash FLA files are zips containing a number individual files inside. Often during the drawn out process of saving individual files and then zipping them, flash has a tendency to corrupt saves, especially when saving to network storage.

We recently spent time trying to recover a FLA file and came up with a process that can often recovery corrupt files.


The Solution

1. Install and open Winrar.  

2. Take a copy of your corrupted FLA file and open it with Winrar. File > Open Archive 

3. Repair the archive. This option is available from the Tools menu.

4. Choose a location to save the repaired archive to.
 

5. Use Winrar to open the file you saved in step 4.
File > Open Archive > select the location you saved the repaired archive to > select the archive 

6. Click "Extract To" and choose a location to extract the repaired FLA file to. This will unzip the FLA zip file into the individual files that are contained inside. 

Accept any errors, it may complain of CRC errors or say some files can't be extracted.  

7. Go to the location you extracted the archive to in step 6. Open the XFL file with Flash, it should have the same name as your original FLA file.  

On a computer with flash you should be able to double click it.

Your file should open damage free! Depending how damaged the archive is this may not work, however we found on most occasions it does and saves you a heap of time.

TMG 2010 Certificate Enrollment Fails - RPC server is unavailable

During some recent TMG 2010 maintenance, we noticed the TMG computer certificate had expired a few months earlier, this should never occur as our Active Directory CA should re-issue a certificate when expiration is near.

We first attempted to manually re-request the certificate via the Certificates MMC snap-in and were presented with an error saying "The RPC server is unavailable."

'

Our eventlogs suggested that a DCOM problem may have occurred. After checking DCOM and the RPC Service we were unable to uncover any issues.

The Solution

It turns out TMG itself introduces this error intentionally. The "Enable strict RPC compliance" setting, which is enabled by default, blocks the RPC functionality required for AD based certificate enrollment to work. Fortunately the fix is straight forward.

1. Open your TMG console 

2. Navigate to "Firewall Policy" 

3. Right click "Firewall Policy", select "All Tasks", select "System Policy" and finally select "Edit System Policy"
 

4. Under "Authentication Services" select "Active Directory 

5. Untick "Enforce strict RPC compliance
 

6. Click "OK" 

7. Apply the policy changes

You should of course do the appropriate research before disabling this setting, in some super high security environments you may not wish to disable RPC compliance, however in our environment it made no difference.

After waiting a few minutes for the policy changes to occur our problem was resolved, certificate enrollment once again worked perfectly.

Newegg TV interview for GSKILL at Computex 2013

I just thought I'd throw this Youtube link up. During Computex 2013 this year I spent a week doing liquid nitrogen overclocking demonstrations at the GSKILL booth with Hiwa Piori and Christian Ney. Our goal was to break world records and get the crowd having fun with liquid nitrogen and high end computer components.

Newegg TV dropped by to see what we were doing and ask a few questions about Haswell and overclocking. My (Youngpro) interview starts around 9:15.