If you want to manually run DirSync to force synchronization of your on-premise Active Directory with Windows Azure Active Directory (WAAD) you can use the following method to perform a sync via the MIIS Client…
- Launch Windows Explorer and browse to the C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell directory.
- Click on the Management Agents button on the top menu bar
Right-click on “Active Directory Connector” and choose Run from the context menu.
Highlight “Full Import Full Sync” and choose OK.
The State will change to Running. The bottom half the screen will give information on any changes that it makes during the run as well as any errors encountered.
Below are some random lessons I learned doing my first Exchange 2013 deployment. Hope they help!
Exchange 2013 Versions
As of the time of this writing the third Cumulative Update (CU) is out for Exchange 2013 RTM. Cumulative Updates are similar to Update Rollups in previous Exchange versions in that they don’t require schema changes, etc. however they are full releases of the product similar to Service Packs in Exchange 2007/2010. So you don’t need to install Exchange 2013 RTM and then CU3, you can just do the install straight from the CU3 source (which is also why the Cumulative Updates are so large). You can download Exchange 2013 CU3 from here…
As in Exchange 2007/2010, Microsoft has a really good install guide that walks you through installing/configuring all of the prerequisites needed for the various roles and OS combinations in Exchange 2013. They make it pretty simple. Basically you just copy and paste PowerShell commands and follow links to software downloads. Now, if only they would just build this into the setup routine for Exchange like they did with TMG Server. You can find the prerequisite guide here…
Active Directory prep commands have changed slightly from previous versions of Exchange. Assuming you are installing Exchange 2013 in an existing Organization you would run…
Setup /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup /PrepareAD /IAcceptExchangeServerLicenseTerms
Setup /PrepareAllDomains /IAcceptExchangeServerLicenseTerms
Accessing the Exchange Admin Center
The Exchange Admin Center (EAC) replaces the Exchange Management Console as the GUI interface for Exchange 2013 management (the Exchange Management Shell is still alive and well and needed more so with Exchange 2013 than was needed for Exchange 2010). If the account you are using for installing Exchange does not have a mailbox one will be created during installation. That makes accessing the EAC simple. You just browse to https://CasServerName/ecp and you are in. If you already have a mailbox though on Exchange 2010 accessing the EAC is a bit more complicated. If you try to connect to https://CasServerName/ecp you will end up proxied to the Exchange 2010 ECP and be left scratching your head as to what to do next. To keep the proxy from happening use the following URL…
There’s a lot more new/different in Exchange 2013 but hopefully this will get you headed in the right direction.
The following steps should be performed when the SSL certificate on your ADFS Server is close to expiring. You will start to receive a warning in the Office 365 Portal about 30 days prior to expiration…
- Make sure you know the username and password for the main domain.onmicrosoft.com Administrator account
- Install the new certificate on the ADFS Server
- Make a note of its thumbprint value
- Bind the new certificate to the Default Web Site in IIS
- Launch the “Microsoft Online Services Module for Windows PowerShell” PowerShell
- Run “Add-PSSnapin Microsoft.Adfs.Powershell”
- Run “Set-ADFSCertificate -CertificateType Service-Communications -Thumbprint ThumbPrint” where ThumbPrint is the value from Step 3 in the Preliminary Steps section
- Run “Update-AdfsCertificate –Urgent”
- Run “Connect-MsolService” and enter your Office 365 credentials from Step 1 in the Preliminary Steps section
- Run “Update-MsolFederatedDomain -DomainName “domain.com”” where domain.com is the appropriate domain name. Note you may need to add the “-SupportMultipleDomain” depending on how things were initially setup
- Restart the AD FS 2.0 Windows Service
- Run “IISRESET” to restart IIS and its services
- Attempt to login with an ADFS account and verify the certificate warning is gone
By default, if you are an Office 365 Administrator you will not be able to view your User Quarantine in Forefront Online Protection for Exchange. The following article discusses the problem and offers a workaround…
The basic premise is you will need to temporarily remove yourself from Administrator roles in Office 365, create the quarantine and then add yourself back to the Administrator Roles.
Important safety tip: Make sure you have another Office 365 Administrator account first…
If you receive the error “Not Authorized: HTTP Error 401. The requested resource requires user authentication” when trying to connect to your ADFS Server from inside the network here’s what you need to do to reset permissions in IIS…
- Launch the IIS Management Console and browse to Default Website
- Disable all Authentication options for the Default Web Site as well as the ADFS and LS Virtual Directories
- Enable Windows Authentication on the Default Web Site. Set Extended Protection to “Accept”
- Enable Anonymous Authentication on the ADFS Virtual Directory
- Enable Windows Authentication on the LS Virtual Directory. Set Extended Protection to “Accept”
- Run an IISRESET
To setup your browser to automatically authenticate you while connected to the internal network do the following…
- Open Internet Options in IE and click on the Security tab
- Click Local Intranet
- Click Custom
- Under the User Authentication section enable “Automatic logon with current user name and password”
- Click on the Advanced tab
- Under the Security section enable “Enable Integrated Windows Authentication”
More information on this can be found at the following Office 365 Forum post…
An Exchange 2007 CAS Server/Exchange 2003 Front End Server can’t proxy requests to Exchange 2010 mailboxes. Nor can an Exchange 2010 CAS Server proxy requests to Exchange 2003/2007 mailboxes (the one exception is Exchange ActiveSync). While an Exchange 2010 CAS Server can’t proxy, it can transparently redirect clients to an Exchange 2007 CAS Server / Exchange 2003 Front End Server though. Typically we would do this as follows.
The current configuration looks like this…
We would then stand the new Exchange 2010 environment in parallel to the Exchange 2007 environment. Note that I drew the ASA and ISA Server as two icons for clarity but in both cases we’re just talking about a second IP address on the same device.
At this point everything would be published and testable but no redirection would be occurring. Here comes the first step were we actually impact users. We would change the External URL values for OWA, EWS and Offline Address book on the Exchange 2007 CAS Server to point to legacy.domain.com (for Exchange 2003 we would add the Exchange2003URL value to the Exchange 2010 CAS Server) so Exchange 2010 would know where to redirect traffic. We would then swap IP addresses between the Exchange 2007 and Exchange 2010 Servers…
Now, when clients type owa.domain.com they would hit the Exchange 2010 server. If their mailbox is here they would stay put however if their mailbox is still on Exchange 2007/2003 their browser would be redirected to legacy.domain.com which would send them into the Exchange 2007 Server. We can now move mailboxes at our leisure. Once they are all moved we can tear out the temporary legacy stuff and we’re left with this…