Our Technical Findings While Developing EBS v2
[Today’s post comes to us courtesy of Alireza Farhangi]
During the development of EBS v2, we tackled quite a few challenges in integrating Microsoft server technologies. We developed solutions and workarounds, proved them through exhaustive testing, and implemented them in EBSv2. Due to external factors, EBS v2 did not release to public. Therefore, we decided to gather some of our solutions and findings, and share it with our community.
1. Performing an 'isolated' installation of Exchange 2010
There is no supported way to rollback a failed Exchange installation from the forest. However, there is a proven way to control and contain the Exchange installation inside the forest, so that in case it fails and blocks, it doesn't spread across the domain and leave the forest in an undesirable state. We implemented this approach in our automated EBS v2 installation and verified it in Beta and RC0 releases. A generalized version of this solution is presented below:
1. Select the Schema master domain controller in the domain you wish to install Exchange in. You must select the Schema master because Exchange installation starts by extending the schema and this operation c6. Use n only be targeted to the schema master.
2. Ensure a full inbound and outbound replication has completed to this domain controller and the DC is healthy (no concerning errors in eventlog, dcdiag, etc.).
3. Disable the outbound replication channels to the DC. You can do this with repadmin.exe /options +DISABLE_OUTBOUND_REPL. This step effectively isolates the DC from the rest of the domain and all changes on this DC will remain exclusively on this DC.
4. Install Exchange 2010 on any server in the domain that can contact the isolated DC, while targeting the installation to the isolated DC. It is very important to target the installation to that DC, else Exchange will pick any DC that finds best. You can use Setup.cmd /DC:<isolated DC name> to target the isolated DC.
5. If Exchange installation fails and you get blocked recovering from the failure, simply force-demote the DC and re-promote it again. This demotion will take all the Exchange residues with it and the new DC, like all other DCs will be unaware of the Exchange failure.
6. If the Exchange installation succeeds and passes your verification, then re-open the replication channels (repadmin.exe /options -DISABLE_OUTBOUND_REPL) and allow a few minutes for all DCs to see the changes. The replication latency depends on the size of the domain and speed of connections.
2. How to work around FSE installation issues on an Exchange server running on top of a DC?
If you are installing the Forefront Security on an Exchange server the setup executable will stop the Exchange Information Store and Transport services, configure Exchange, and restart the services. FSE will wait up to 120 seconds for the Exchange services to start up again and if they don't, it will error out. Typically Exchange Information Store and Transport should both start within 120 seconds, however, we did experience that occasionally the service takes longer to start, especially when Exchange is installed on a Domain controller.
If you encounter such a problem with FSE installation, simply stop the Exchange Transport and Information Store services and retry FSE setup. FSE will only attempt to start the services if they were initially running. Else, it will simply complete setup, report success, and leave the services untouched. FSE installation typically requires a reboot, which will automatically restart the Exchange Information Store and Transport services.
3. How we solved problems with Exchange running on a Domain Controller in EBS
The detailed article can be found at:
4. How to recover EBS 2008 Messaging server objects after an accidental Active Directory server object deletion
The detailed article can be found at:
5. Integrating the all new Exchange Pre-deployment analyzer into deployment planning
Several years ago Exchange released an Exchange BPA v2.8 that could be deployed on (almost) any domain-joined machine and examined the 'readiness' of the domain and forest for an Exchange installation. Exchange discontinued this stand-alone tool until recently, that they released Exchange Pre-deployment analyzer for Exchange 2010. This tool is also standalone and can even run from a domain-joined Vista client. You can find the ExPDA at: https://www.microsoft.com/downloads/details.aspx?FamilyID=88b304e7-9912-4cb0-8ead-7479dab1abf2&displaylang=en
We certainly recommend that as part of your deployment planning run the readiness checks of this tool. You can also automate the process with a VB script that executes ExPDACmd.exe, dumps the report in an XML file, and read the Errors out of the file using searchExpression = "//Message[@Error='Error']".
6. Use the Exchange Remote Connectivity Analyzer:
The https://www.testexchangeconnectivity.com is a great resource for anyone to test whether they have setup the ActiveSync, EWS, RPC over Http, SMTP, etc. settings correctly. The ActiveSync test will simulate a mobile device and test connectivity. The Outlook tests simulate an Outlook connecting via Outlook Anywhere. The SMTP tests will walk through all steps for an inbound and outbound email delivery.
7. Installing Remote desktop gateway and publishing in ISA/Forefront TMG
https://technet.microsoft.com/en-us/library/cc771530(WS.10).aspx provides in depth details on how to configure Remote desktop gateway (formerly TS gateway) in various scenarios.
8. Publishing OWA in ISA
Following article provides information on how to configure OWA in ISA https://support.microsoft.com/kb/290113