Friday, November 19, 2010

Application Packaging

Uniphi 1.3.02
This one was a crazy program to package. Firstly the upgrade doesnt work well from the previous version, and even getting it to work stand alone was difficult when running on Windows 7. To cut a long story short, it was determined that Uniphi would crash when trying to execute the program- but only if Office is installed.

To troubleshoot the issue, I installed Office and Uniphi on a single machine and ran up process monitor. Filtering through 65000 lines of junk is not fun. So jumpstarted the process by searching for the term "Office" which turned up a single instance where Uniphi was trying to start a program under the OFFICE14 folder in common files. The program turned out to be the Microsoft Office XML viewer. Also going back in the processes prior to this, I could see that it was using the registry HKEY_CLASSES_ROOT to determine the XML program to run. This led to following the different trails of CLSIDs until I finally come to an "text/xml" key under HKEY_CLASSES_ROOT\PROTOCOLS\Filter.
This looked interesting. Anything that is filtering the XML could cause problems! I removed this key and this time the program cranked up with no errors!
It turns out that Office installs an XML MIME filter that runs even for custom programs (such as uniphi) and it is this filtering that Uniphi has a problem with.
You'd think people would test their programs against a computer where other common programs are installed.

Thursday, November 11, 2010

Exchange: Migration Issues

Interorganizational Migration Issues

Issue: Mailbox is migrated from Exchange 2007 to Exchange 2010. The console says that the migration is completed. The user cannot access their mailbox through OWA or the Outlook client. OWA returns stack trace report.
Resolution: Suspect due to Active Directory replication and the System Attendant. If the system attendant has not been able to run over the users then they will not be able to access the mailbox until it does. This may be a 2 hour waiting window and even longer if AD is not fully in sync.
- Check that CAS servers are using domain controllers in their own site.

Issue: Mailbox is migrated from Exchange 2007 to Exchange 2010. Users clicking on Calendar in Outlook receive an error saying that Exchange must be online to connect.
Resolution: Wait until all items have been downloaded and completed syncing the offline copy. To track the progress, right click the icon in the system tray and select Connection Status... Select Local Mailbox tab to determine what is currently syncing. In some cases it is simply a case of waiting for AD replication and System Attendat activities to happen.

Issue: Mailbox is migrated from Exchange 2007 to Exchange 2010. Users are unable to set OOF or have issues with other availability services such as free/busy, calendaring, scheduling, etc.
Resolution:
Run the "Test E-mail Autoconfiguration" from the client and check if it is receiving autodiscover.xml. If not, determine why this is the case. If you are connecting to Outlook from a computer that is not logged into the target domain, then it will need to be able to connect to autodiscover.domain.com in DNS. You should not make this change in DNS when you are performing interorganizational migrations. This can cause users who have not been migrated across to pick up the new autodiscover and start trying to use some servers that are in the target Exchange organization. This will mean users are prompted to provide credentials to servers that they may not yet have access to. A better solution is to create a autodiscover host name in a local HOSTS file to point to the CAS server so that the change is not global.

Issue : Users are unable to access calendar immediately following migration of mailbox – rest of mailbox is accessible
This issue resolves resolved itself on all occasions within an hour of migrating the mailbox and once mail is fully cached in the OST.

Issue: prompted for second password when accessing calendar within the migrated mailbox.
This issue can be resolved by adding autodiscover to the local host file.

Issue: Users are unable to access OOF from Outlook internally.
This issue is only proven to affect Outlook 2007 at this stage as a number of users are using this function fine with Outlook 2010. This issue can be resolved by adding autodiscover to the local host file. A workaround is to use OWA to connect directly to a CAS server/array in the same site as the mailbox.

Issue: Primary email address is set incorrectly on migrated mailboxes.
Create a new email address policy to set the correct email address on mailboxes as they are migrated. A email policy based on OU can only be created if there are no Exchange 2003 servers in the organization. Otherwise you can use "State or Region" or another identifer.

Issue: One of the SiteA CAS servers is pointing to SiteB domain controllers.
One of the SiteA CAS servers is pointing correctly to the local domain controllers in the site, however the other one is pointing to SiteB Domain Controllers. A suspected impact of not resolving this issue is that mailboxes may take longer to become available to end users following migration. It is possible to force a CAS server to use a specific set of domain controllers however this is not a desirable configuration for the long term. Look in the application event log of the Exchange server in question and find the information message that is logged by the Exchange Topology Generator. Check firstly that Exchange thinks the correct servers are "in-site". Then check the numbers to ensure the local DCs are seen as GC's, and that the SACL digit is set to "1" (true). If Exchange cannot read the SACL on a domain controller then it will refuse to use that domain controller. DSAccess does not use any domain controller that does not have permissions to read the SACL on the nTSecurityDescriptor attribute in the domain controller. To check this, check the local security policy and also the Default Domain Controllers Policy for the Computer Settings\Windows Settings\Security Settings\User Rights Assignment. Open the "Manage auditing and security log" and ensure that Exchange Servers and Enterprise Exchange Servers are assigned this right either locally or through Group Policy. If assigned through group policy, then ensure group policy is applied using GPResult /R, and that computer configuration is not disabled within the group policy. The Exchange DomainPrep process should complete this process automatically however if there is an issue then this may not have applied to some domain controllers. See http://support.microsoft.com/kb/316300 for more detailed information on resolving issues that are detected with the Exchange Topology generator event log entry. Also see http://support.microsoft.com/kb/314294/EN-US/.

Issue: Users are unable to access Options section of OWA using most Internet Browsers
This issue affects all migrated users in a particular site. Based on errors in the event log on the CAS in the central site, you may find errors that it was unable to proxy ECP traffic to the CAS servers in the local site due to Windows authentication being disabled. Recommendation is to change the ECP virtual directories on the local sites CAS servers to allow Windows Authentication. If this does not work, then Windows Authentication may also be required on the CAS in the central site.

Issue: Mailboxes in the console stop migrating and return errors if you view the properties of the move request, or try to remove the move request.
This issue is most likely due to the log drive running out of space. When this happens on Exchange 2010, it will stop sending and receiving email, and users will also lose connection to their mailboxes. You will find about 4MB of free space left on the drive, which Exchange will try to maintain in order to prevent corruption of the logs.
Resolutions: If your database is part of a DAG then your options are limited. If not part of a DAG however, you can move the log files to another drive that contains more space. If part of a DAG, your best option is to shutdown the servers in the DAG and expand the log drive if this is possible. If either of these options is not available then you can use ESEUTIL to determine the checkpoint and manually move any previously committed log files to a backup drive. Another option would be to switch the database to circular logging however this will limit your options for a recovery should one be required. If you switch to circular logging you may need to restart the IS on the mailbox servers. This last option has not been tested by me in this particular scenario where space has already been depleted.

Interorg migration refuses to migration because the mailbox in question does not have an msExchMasterAccountSID attribute
Resolution. Either set the msExchangeMasterAccountSID (associated owner) or enable the account for the migration.

Mailbox has been prepared for interorg migration however when trying to migrate the mailbox it complains that the msExchangeGuid is missing
This can happen if Exchange is pointing to a DC in a different site (this is an issue in itself). Try replicating all pertinent Active Directory connections.

When trying to queue a new mailbox move request, it times out with an error similar to did not receive a reply within the configured timeout (00:01:00).
This means that too many requests are most likely being backlogged through the CAS server. This error message is related to NET.TCP port sharing service and can be resolved by modifying the SMSvcHost.exe.config in the Windows Foundation folders on the CAS server where you are running the command. Note that on 64-bit Windows there is a x64 folder and an x86 folder. I would suggest making any changes to both of these files. Make sure to backup the files first, and note that you cannot edit the files in place as they are constantly in use. You will need to copy elsewhere, make the modifications, then copy it back to the location again. Note that any changes to this file will affect all services that use the NET.TCP port sharing service. No services need to be restarted and the change takes effect almost immediately.
The option that will generally be changed is the maxPendingAccepts which is set by default to a conservative 2. You can try upping this amount to 10 instead.

For more information about this file, see:
http://msdn.microsoft.com/en-us/library/aa702669.aspx
http://blogs.msdn.com/b/andreal/archive/2009/04/05/net-tcp-ip-port-sharing.aspx

According to the second URL, you can also try setting maxPendingConnections to 1000 and the listenBackLog to 100.
"As far as concerns the maxPendingConnections and maxPendingAccepts settings, our defaults are intentionally conservative so that customers must opt-in to allowing large amounts of work into the system. "
"It's hard to recommend some values, because it depends on the applications running on the system; you have to keep into account the user could have some other services using TCP Activation with WAS, which your application has to share SMSvcHost.exe resources with. According to the Product Team, you shouldn't increase “maxPendingAccepts” too much. 5-10 would be a good number. It means it spawns 5-10 concurrent threads to pull connections.
Feel free to increase the maxPendingConnections value according to your needs (you can also set 1000, even though I'd wonder why if you needed so many connections. 100-200 can be considered a good choice). "

Basically, look at the SIDs to see what services are allowed to use the NET.TCP port sharing and then determine how many connections each service may require. This can be used to give a more educated figure than the suggestions above.

When assigning send as permissions through the EMC, it does not take effect on the client
Use the EMS: -
get-mailbox "mailbox name" Add-ADPermission -ExtendedRights "Send As" -User "Name of user"

Needed an easy way to assign Send On Behalf of permissions for shared mailboxes and distribution lists.
Powershell provides the -GrantSendOnBehalfTo attribute for Set-Mailbox and Set-DistributionList command lines. You might use the following command to grant users permissions on a number of shared mailboxes:

Get-Recipient -PropertySet ConsoleLargeSet -ResultSize '1000' -SortBy Display
Name -RecipientType 'UserMailbox' -Filter '((DisplayName -like ''*shared1*'' -or DisplayName -eq ''shared2''))' Get-Mailbox Set-Mailbox -GrantSendOnBehalfTo "User1","User2"

New email address policy is created in the target which applies email address that is shared between the two organizations. Email stops flowing to the source organization.
When you set an accepted domain to authoritative, it will never try to deliver mail to that domain outside of the Exchange organization. There is a catch however. If there is no email policy referencing that accepted domain, then the Exchange organization will still try to deliver outside the organization. As soon as an email address policy is created, this authoritative nature then appears to take effect and preventing the delivery outside the organization.