iPhone IOS4 Issues

As any iPhone enthusiast knows, IOS4 has been released. Unfortunately there have been a large number of reports of issues surrounding IOS4’s implementation of ActiveSync.

Issues reported include dramatic increases in resource usage on Exchange servers (causing potentially severe issues), issues with iPhone sending and receiving mail, and issues with iPhones not syncing correctly with regards to their mail and calendar items.

Apple has released a single update, but it only addresses one of the seemingly many issues. My company, Azaleos, is currently taking the stance of advising customers to hold off on upgrading until Apple and Microsoft work out these issues.

Additional Links:

http://msexchangeteam.com/archive/2010/07/01/455342.aspx?CommentPosted=true#commentmessage

http://support.apple.com/kb/TS3398

Prevent Double-Booking Rooms in Exchange 2007

My new responsibilities leave me little time to post, so I figured I'd dump a quick PS execution for admins quickly searching for a way to avoid double booking in their environment.

get-mailbox | where {$_.ResourceType -eq "Room" } | Set-MailboxCalendarSettings -

AutomateProcessing AutoAccept -AllBookInPolicy:$true -AllowConflicts:$false

ResourceType can be substituted for other types than Room as well.

Digicert Intermediate Cert Eclipsed by Root - ActiveSync issues

We recently ran into an issue where using a new Digicert certificate essentially broke activesync for most people in the company. The issue is that the new root certificate for Digicert isn't compatible with older browsers and devices (they don't come standard with the new root certs for Digicert like they might with Verisign and others). The primary phone of the organization was a Motorola Q, which made the issue quite visible.

The problem boiled down to this root cert taking precedence over the intermediate cert (Digicert calls it eclipsing which I suppose is a more valid term), which would have worked fine. After the Digicert Root Cert was removed, the issue was resolved.

Note: Be sure that the intermediate is in place and functioning or else you will break all of the modern phones and browsers as well.

Also as an alternative fix, you could install the root cert on the phones in question. This is more labor intensive, but might be viable if there are only a few old straggler phones floating around.

Reference:

https://www.digicert.com/ssl-support/windows-cross-signed-chain.htm

You can also run a good test for this and other issues at:

https://www.digicert.com/help/

SMTP Categorizer Queue Length Spikes

The issue has cropped up with the Categorizer Queue Length intermittently spiking.  First off what is the Categorizer Queue Length?

This counter basically determines the items that reside in the categorizer queue.  The categorizer does a few things.  It resolves/validates recipients, determines whether the message should be queued for local or remote delivery, expands Distribution Lists (DLs), and detects limits and restrictions.

The first thing to check in order to resolve the spikes, would be that there are ample Global Catalog servers (GCs) and Domain Controllers (DCs) in the environment to perform the look-ups.  The best way to check this is on the DSAccess tab in ESM (2k3), or the System Settings tab under the properties of the Exchange server (2k7). 

It would also be prudent to run a network diagnostic tool in search of a bottleneck.

Microsoft also recommends monitoring the processor utilization of Inetinfo.exe (categorizer component) and using the e2kdsinteg config object from the ConfigDSInteg tool in order to check for malformed objects that could be slowing the process of directory look-ups.  You can get the tool here.

Knowing that the environment probably wasn't the shining star on the top of the Active Directory hill, this was the first thing to check.

The e2kdsinteg log came back with numerous entries for old mail servers, and objects not seen by human eyes in many moons.  My advice was to continue to run diagnostics for bottlenecks, and to investigate the purging of these rogue/malformed objects.

Outlook Anywhere Failing - RPC End Points - 6004

It was brought to my attention that autodiscover was not behaving correctly externally.  I ran it through Microsoft's Exchange connectivity tester @ http://www.testexchangeconnectivity.com/ and received the following output:

To resolve this first simple part I just went into the EMS and gave it an ExternalURL via:

Get-AutodiscoverVirtualDirectory | set-AutodiscoverVirtualDirectory -ExternalUrl https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

I now received this error:

"Failed to ping RPC Endpoint 6004 (NSPI Proxy Interface)"

..and also RPC_S_SERVER_UNAVAILABLE error (0x6ba) was thrown by the RPC Runtime

Most curious about an RPC error at this level.  Perhaps a connection between the Hub/Cas and MBX server or MBX server and AD/DCs/GCs?  The environment was not 2008, nor was it using IPv6.

The following is what fixed my issue:

Using the configurations here I was able to remedy the situation.  Basically what happened was that it could not use DSPROXY via HTTP, and it is a known issue.  The fix is to:

1. Changes for Mailbox servers..

a. create a DWORD called "Do Not Refer HTTP to DSProxy" at HKLM\System\CCS\Services\MSExchangeSA\Parameters\ and the value set to 1.  This will, as it spells out, stop it from trying to use DSProxy when using HTTP.

b. HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the domain controller that you would like used for profile creation.

2. Changes for Client Access Servers..

a. Ensure that the "PeriodicPollingMinutes" key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\ is set to zero.  This will ensure that the system won't continue to over write our settings every 15 minutes.

3. b. Also modify "ValidPorts" at HKLM\Software\Microsoft\RPC\RPCProxy such that it lists the DCs which can be accessed via port 6004.  An example of this would be:

domaincontroller.domain.com:6004;domaincontroller2.domain.com:6004

4. Changes for all Global Catalog (GC) servers..

a. Be sure that there is an REG_MULTI_SZ entry created named NSPI interface protocol sequences at HKLM\System\CurrentControlSet\Services\NTDS\Parameters\ and the value set to "ncacn_http:6004"

Testing autodiscover/Outlook anywhere now yields the following output in the connectivity tester:

You can double check these settings by configuring a profile in Outlook, then Ctrl+RightClicking the outlook icon on the system tray, and running "Test E-Mail Autoconfiguration."

For the full explanation I highly recommend reading the official blog post by Siddhartha Mathu at:

http://msexchangeteam.com/archive/2008/06/20/449053.aspx

Good read!

Warning 2601, errors 2604 and 2501

Recently we received the following errors on a client:

Warning 2601, errors 2604 and 2501 -- In the event viewer.

A series of things can fix this issue.  

1.  Verify the Exchange server(s) is a member of the "Exchange Servers" and "Exchange Install Servers" groups.  Verify that these groups are under the manage/audit rights for the default domain policy (Under local policies -> user rights assignments). 

2. It could be related to the order Exchange services start up.  I think this was the right order:

"Microsoft Exchange Active Directory Topology Service" 

"Microsoft Exchange Anti-spam Update" 

"Microsoft Exchange EdgeSync" 

"Microsoft Exchange File Distribution" 

"Microsoft Exchange IMAP4" 

"Microsoft Exchange Information Store" 

"Microsoft Exchange Mail Submission" 

"Microsoft Exchange Mailbox Assistants" 

"Microsoft Exchange POP3" 

"Microsoft Exchange Replication Service" 

"Microsoft Exchange Search Indexer" 

"Microsoft Exchange Service Host" 

"Microsoft Exchange System Attendant" 

"Microsoft Exchange Transport" 

"Microsoft Exchange Transport Log Search" 

"Microsoft Search (Exchange)" 

3. The one that actually fixed the issue for me was to simply restart the Net Logon service and the "Microsoft Exchange Active Directory Topology Service."

How to Publish More Free Busy Data

It has been a bit since I posted, so I figured I'd toss out some easy fodder for those that don't know (which seems to be a lot more than I thought initially).

Unfortunately there is no quick easy server side change to publish more free/busy data for a user.  It is a client side setting.  The setting itself can be deployed this way:

Tools -> Options ->Calendar Options-> Free/Busy Options -> Permissions Tab -> Other Free/Busy.. -> Modify the number of months to publish.

Being a client side change, if you want to roll it out on a mass scale you'll either have to build it into your ghost images, or you'll have to roll out a GPO/login script.  I went to find the exact one, and ran across the Exchange team's blurb on it:

http://msexchangeteam.com/archive/2004/06/10/152698.aspx 

Using LDIFDE & ADSIEdit to Verify Recipient Policies

Originally I wanted to run something like this:

ldifde -f C:\test.txt -t 3268 -s DC.domain.com -j C:\ -r "(&(|(mailnickname=*)(objectClass=user))(|(homeMDB=*)(msExchHomeServerName=*))(userPrincipalName=*@domain.com))" -l "msExchPoliciesIncluded"

Unfortunately userprinicipalname doesn't play nicely with  "msExchPoliciesIncluded."  I'm guessing this is the case with more than one user defined attribute.  Example output:

dn: CN=sname\, gname,OU=Users-Company,OU=User,DC=Corp,DC=com

changetype: add

If we change it to reflect only objectclass=user:

ldifde -f C:\test.txt -s DC.domain.com -j c:\ -r "(&(objectClass=user)(homeMDB=*))" -l "msExchPoliciesIncluded"

It pulls this as example:

dn: CN=sname\, gname,OU=User,DC=domain,DC=Corp,DC=com

changetype: add

msExchPoliciesIncluded: 

 {86129EE7-F6C7-4CE2-9549-C242356184C6},{3B6813EC-CE89-42BA-6F11-D87D4AA30DBC}

msExchPoliciesIncluded: 

 {7DF5DEB4-C2EA-4920-BC8C-5342BC1E95E6},{26491CFC-4EB1-4857-861B-0CB8DF22B5D7}

You can also find this in adsiedit here to verify:

Tricking Exchange - A Different Database Move

The issue arose of moving a database to a new location.  Now there are built in commands for this:

FOR LOGS:

Move-StorageGroupPath -identity SERVER\StorageGroup -LogFolderPath X:\PathToLogFiles -SystemFolderPath X:\SystemFolderPath

FOR DATABASES:

Move-DatabasePath  Server\StorageGroup\MailboxStore -EDBFilePath X:\PathToDatabase

The problem was that we wanted to specifically use eseutil to move the databases.  We used eseutil to push a good copy over, however, we couldn't repoint the database without Exchange trying to copy it over.  I believe you can repoint the registry, but we opted to just trick Exchange in a manner of speaking.  Due to size constraints, we created a new empty database, ran the above command to move it, then deleted the new database and replaced it with the eseutil copied one.  This mounted up and worked great.

An alternative method to the normal methods of moving it over if you have odd circumstances to work under.