Thursday, July 28, 2016

Exchange Lagged Database Copy-DAG

Microsoft introduced lagged copy concept in Exchange 2007, when we are configuring the Standby Continuous Replication (called SCR). In Exchange Server that will hold an additional copy of the Mailbox Database. This is not for High Availability solution but for the disaster recovery solution. A lagged copy is the copy of the mailbox database that has certain lag time, this copy is certain amount of time behind the production server. The log file are copied to the SCR server immediately, but they are replayed into the Mailbox Database only after a specific, configurable time. This is also called lag time.
As we all know in Exchange Server we can configure the Database Availability Group (DAG) and a Database Availability Group also hold a legged copy. In DAG the lagged time can be up to 14 days. In this scenario the log files are copied from the Active Database to the passive Database, but they are replayed into the Database only after 14 days, means we can say we need quite an amount of the disk space to accommodate 14 days of log files.

So a few things to keep in mind when doing this process – If you have lagged copies of your databases you might want to make sure they can’t ever be activated. Because that would be very bad as you would lose the lag. In my case I lag for 8 days on my lagged copies.  In the EMC, it will always show a Activation Preference even if you have blocked the activation so it’s always good to set this when adding a copy of your database.

Let’s take a look, how we can add new database to the DAG

Create a new Database in your DAG and mount the Database.

Add Mailbox Database Copy to add the copy to your other mailbox servers.

Set your lag copy up.  This is done via Powershell.

Block the activation so it can’t ever fail over to the lag copy unless you do it manually.

When the cmdlet is run with the “-ActivationOnly” parameter, the database copy cannot be activated unless you do it manually.  

NOTE: You can run this command for every database on a server (if you have a server dedicated to hosting your lagged copies for example) this is done like this:

To disable this set the -databasecopyautoactivationpolicy to “unrestricted”

ACTIVATING A LAGGED DATABASE COPY


1. Identify the lagged copy of the database 
Get-MailboxDatabaseCopyStatus DB5 | Where {$_.ReplayLagStatus.Enabled -eq $true} | ft -auto
2. Now suspend the lagged copy of the database
C:\>Suspend-MailboxDatabaseCopy DB5\MX1
3. Make sure the backup of the database and log file for lagged database copy, or     we can simply copy to another location in server itself.
4. Once you have safe copy of your database & logs delete the .chk file from           transaction log in original location.
5. Use ESEUtil for dirty shutdown eseutil /mh c:\Exchange\DB5.edb, it will   
    show you dirty shutdown status of the database.
6. Next step run the soft recovery eseutil /r e00 /a
7. Again check the database status with help of /mh command.
8. Now database can be copied to another location and used as a recovery 
    database for restore purpose.

The lagged database copy automatically can be resumed as well.

You can also activate a lagged mailbox database copy by using SafetyNet recovery-check here 

Sunday, July 24, 2016

Publishing Exchange Server 2016 "Outlook Web App" to the Internet with AD FS

We can Publishing Outlook Web App via Web Application Proxy with using the Integrated Windows Authentication. Web Application proxy performs pre-authentication as required and can be perform SSO to the published  Windows  authentication we must add a non-claims-aware relying party trust for the application to the Federation Service.

To publish OWA uses claims for authentication, we must add a relying party trust for the application to the Federation Service. When publishing claims-based applications and accessing the application from a browser, the general authentication flow is as follows:


  • The client attempts to access a OWA using a web browser; for example, https://mail.tech.com/owa/.
  • The web browser sends an HTTPS request to the Web Application Proxy server which redirects the request to the AD FS server.
  • The AD FS server authenticates the user and the device and redirects the request back to Web Application Proxy. The request now contains the token. The AD FS server adds a single sign-on (SSO) cookie to the request because the user has already performed authentication against the AD FS server.
  • Web Application Proxy validates the token, adds its own cookie, and forwards the request to the Exchange server.
  • The Exchange server redirects the request to the AD FS server to get the OWA security token.
  • The request is redirected to the Exchange server by the AD FS server. The request now contains the application token and the SSO cookie. The user is granted access to the OWA.

Setting up ADFS server


From ADFS server manager add the ADFS server role, once finished the installation the ADFS role, now time to configure ADFS server
Select configure federation server and we are creating new ADFS server so select "create the first federation server in a federation farm"

Now we need to select the user which will configure ADFS server

Once we select the user than select the SSL certificate and Federation server Name
Again now we have define the account details

Now time to configure the configuration database, here we are configuring into lab so we will select the first option, if you are installing more than 5 ADFS farm than you have to define the SQL server for configuration database.

Now time to review the configuration 


Now you have to check the pre-requite check

Now you have to open ADFS management console

Verify the ADFS configuration 


Now we need to add a non-claim aware relying party trust via wizard





Define the name and description
Now add your URl which you want to publish for me "https://mail.tech.com/owa/"

In this wizard it will ask for configure multi factor authentication, here we don't want to configure multi-factor authentication



In this wizard default check for "Open the edit Issuance authorization Rules dialog for this non claims-aware relying party trust when the wizard closes"
Once close we will see the edit rule wizard 
Now we are selecting "Permit all users' from drop down box



Now we can see the added rule in wizard 

Now time to test our  ADFS setup is working – you can go to the portal page – https://localhost/adfs/ls/idpinitiatedsignon.aspx

If you see this – continue on!



Configuring Exchange Server


Now we need to change the authentication type for the OWA virtual directory to Windows Integrated Auth (from forms) in order for the delegated authentication to work.

On Exchange Server E16, open the ECP (https://localhost/ecp )

Ignore the cert warning.

Select the OWA virtual directory


Select the "Use one or more standard authentication methods with Integrated Windows authentication"



Configuring WAP (Web Application Proxy) Server


From Server Manager you can add feature "Remote Access" and select required options, once installed add ADFS farm entry on host file in WAP server.


Thank select configuration WAP and follow the instruction


Add the ADFS server details and put the user name and password


Select the certificate


Now you can see the configuration details


Once you completed you can see the "Remote Access" in Server Manager

Open WAP management console





Select option "Active Directory Federation Services" for publishing the OWA

Select the Relying party

Now time to give the details for OWA

Verify the configuration details

Now you can see our configuration successfully published

Now same we have to do for ADFS with using the Pass through




Select option "Pass Through"


Give the details for ADFS



Now you can see both rules are reflecting into WAP console

Now you can see the certificate with help of MMC, which we import here


On DC, we need to configure Kerberos constrained delegation.


Testing


Now time to test publishing Outlook Web App to the Internet with AD FS Pre-Authentication, open the browser and type OWA URL- https://mail.tech.com/owa/


Now it will redirect to ADFS and asking for credential, give the credential


Once you provide the credential  you can see user's OWA is opened



Hope this articles will help you to understand how we can publish Exchange 2016 OWA via ADFS.

Thank You!