Category Archives: Exchange 2010

How to Update DAG Members to SP1 in Exchange 2010

Exchange 2010, High Availability

 

Exchange 2010 SP1 has been released, and comes with a slew of new and exciting features.  Since we are all clamoring to get this installed in our environments, we should discuss how exactly we upgrade the members of our DAG so as to provide zero downtime to our users, and get our systems patched correctly.

From a high level view, remember we should be patching servers in the following order:

  1. Client Access Servers
  2. Hub Transport Servers
  3. Edge Transport Servers
  4. Mailbox Servers

The process we discuss in this article can and should be applied to ALL updates to members of a DAG, not just major updates like service packs.

In our environment we have three total nodes:

  1. NYDAGNODE1
  2. NYDAGNODE2
  3. BOSDAGNODE1

Let’s start with BOSDAGNODE1.  Step one would be to move all active databases on BOSDAGNODE1 to another server.  You want to ensure that it does not have any active databases on it.  We can accomplish this in two ways.

In the EMC navigate to Server Config –>Mailbox.  Select the server in question and then select Switchover Server:

Sep. 2301 10.43

Then you can either automatically choose a target server, or specify one yourself:

image

Or, through the shell, you can run the command:

Move-ActiveMailboxDatabase –Server DKPBOSDAGNODE1

Sep. 2302 10.45

This will do the same thing as the console, and will automatically choose a target server.

Next, we want to block DKPBOSDAGNODE1 from activating it’s databases.  This will prevent other servers from failing over to it.

Set-MailboxServer DKPBOSDAGNODE1 –DatabaseCopyAutoActivationPolicy:blocked

Sep. 2303 10.47

Now you can upgrade the server to Exchange 2010 SP1!

After its finished, run the following command to re-enable activation of the node:

Set-MailboxServer DKPBOSDAGNODE1 –DatabaseCopyAutoActivationPolicy:unrestricted

Sep. 2304 10.50

Now, you can proceed on the other nodes until your finished!

One caveat you need to be aware of.  Exchange 2010 RTM servers can failover TO a dag node member running Exchange 2010 SP1, but a server running Exchange 2010 SP1 cannot failover to a dag node member NOT running Exchange 2010 SP1.  So make sure your entire DAG is upgraded in a timely fashion!

As for your schedule, note that I chose to do Boston, which is our DR site first, because NY would still be able to fail over to it in case of a DR situation.  Next, I can do one node at a time in NY.  This allows me to keep my mailboxes local to my production site, while ensuring that I am covered should a DR situation arise. 

How to Lock Down Activesync Users to Specific Device in Exchange 2010 or Exchange 2007

ActiveSync, Client Access, exchange 2007, Exchange 2010

 

With the recent release of the Apple iPad, the new iPhone, not to mention the numerous Google Android phones available, there has been a dramatic increase in interest in using Exchange ActiveSync along with Exchange Server 2010 or Exchange Server 2007. 

Along with using these devices, comes certain questions regarding security.  One of those topics, covered by this post, is how to restrict end users to a specific ActiveSync device.  Some ActiveSync devices do not support certain features, that Exchange Admins may want to ensure don’t connect to their systems.

For this example, we’ll run the Get-ActiveSyncDeviceStatistics –Mailbox pponzeka command to determine the DeviceID of the users current ActiveSync device:

 

Jun. 2310 08.55

Note the DeviceID listed, 413030303030313542354533744.  This is akin to a serial number for this particular active sync device, its unique per device.  We can lock down this use, so that he can only use THIS device to connect to his mailbox via activesync.

To do so, we simple run the command Set-CasMailbox pponzeka –ActiveSyncAllowedDeviceIDs number1,number2

Jun. 2314 09.16

If we had multiple devices, you would just list both numbers separated by a comma.

If you ever want to remove the restriction, simply enter the null value:

Set-CasMailbox pponzeka –ActiveSyncAllowedDeviceIDs:$null

image

This will set this users mailbox back to the default of allowing all activesync device’s to connect!

Exchange 2010 SP1 Announced

Exchange 2010

The Exchange Team today announced some of the features of SP1 for Exchange 2010.

http://msexchangeteam.com/archive/2010/04/07/454533.aspx

One of the biggest features, is one I’ve talked about before, the ability to provision Archive Mailbox’s onto a separate database, instead of it having to be on the same database as the users regular mailbox.  This will now allow a company to tier their storage more accordingly, making this a viable solution.

Other cool features are the ability to import PST’s to users archive mailbox’s using admin tools, instead of the user having to do it through their outlook.

Another big announcement, is that by the time SP1 is released, there should be an update to outlook 2007 that allows it to connect to a users primary mailbox, and archive mailbox just the way that Outlook 2010 does.

How to Publish Outlook Web Access with RSA SecureID on Exchange 2007 or Exchange 2010

exchange 2007, Exchange 2010, Security, Threat Management Gateway

With many companies putting an emphasis on security, especially given the recent events involving Google and China, one of the things many companies turn to is two form authentication. The most popular brand out there is RSA, a subdivision of EMC.

Those who work with RSA know the deal. You get an appliance that you install on your internal LAN, and give your users a key fob.  This key fob has a display that changes a number sequence every sixty seconds. Users then use this key code, along with their user name and password, to log onto company resources. It’s regularly seen with network resources such as Citrix XenApp and web resources. Another solution where you can leverage it is by securing Outlook Web Access from Exchange 2007 or Exchange 2010 with RSA two form authentication. This means that users would need to use an RSA token along with their user name and password to log onto OWA.

Besides the RSA appliance, you would need also a Microsoft Threat Management Gateway Server (formerly called ISA Server) installed and operational. In the remainder of this article, I’ll show you how to publish the OWA page utilizing RSA for two form authentication.

Our test network is as follows:

1. NYRSA1 (RSA Server) – 10.1.1.100

2. NYTMG1 (TMG Server) – Local LAN 10.1.1.87, Internet 192.168.1.87

3. NYCAS01 (Exchange 2007 Client Access Server) – 10.1.1.12

Remember, with TMG the server generally has 2 NICS, one is connected to the unprotected network, or internet, and one is connected to the protected LAN, or internal network.  With Threat Management Gateway, you can either have it external to the domain, joined to a workgroup, or joined to the internal domain.  In our example, we have the TMG server joined to the domain.

So, the first thing we need to do is make the RSA server and the RSA Agent (in this case the TMG server) aware of each other and allow the TMG server to authenticate users with RSA. Log into NYRSA1 and launch RSA Authentication Manager Host Mode:

From here select “Agent Host” and select Add Agent Host. Fill out the name of the TMG server. (Ensure the server name is resolvable from the host, you can tell if it automatically fills in the IP of the TMG server):

Ensure the Agent Type is set as NET OS Agent and check Open to All Locally Known Users.

Select OK to save the host. Next, we need to export a file that we will import on the TMG server to establish communications. Go to Agent Host, Generate Configuration File and select One Agent Host:

Select the TMG server, NYTMG1 and save the resulting sdconf.rec file to the RSA appliance desktop. Next, move that file to a location on the TMG server that you can access from that server. You may need to use a USB key or CD if your TMG server is set with the default settings, which doesn’t allow remote or network share access.

Next, log onto NYTMG1, and copy the sdconf.rec files to two locations:

1. C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig

2. C:WindowsSystem32

***If you do not copy the sdconf.rec file to C:Program Files location, you will receive an error later on that I will show you***

Next, we need to export a copy of the certificate that is installed on NYCAS01, so that we can install this same certificate on NYTMG1. This is because the TMG server does SSL bridging between the two servers, and needs this certificate in order to unwrap the SSL packets from the client.

On NYCAS01, open an Exchange Management Shell. First we need to figure out the thumbprint for our certificate. You can get this by running the command Get-ExchangeCertificate:

Next, you can export this certificate to a .pfx file with the command above. Note we are exporting the certificate whose thumbprint begins with 331BF.At the end of this command, a logon prompt will appear which will force you to enter logon credentials to password protect the certificate. The prompt forces you to enter a logon name with a domain, but rest assured, it’s the password that’s important.

Now, copy the file export.pfx to the TMG server so you can access it locally, we need to import this certificate. On NYTMG01, open a blank console by running the command mmc and pressing enter. Now, select Add/Remove Snap In and select the Certificates snap in:

Select Computer Account and Local Computer and finish:

Next, navigate to the Personal store and select Import:

Now, the Import Certificate Wizard starts:

Select Next, and browse to the .pfx file you copied over:

At the next screen, select Mark This Key as Exportable, enter the password you created earlier and select next and finish. Now this certificate is available for use in TMG.

Next, let’s start creating our rule to publish OWA. Open the Threat Management Gateway Console and Select Firewall Policy:

Click on Publish Exchange Web Client Access from the Tasks bar on the right, which will start a Wizard. Give the rule you are creating a name:

Click Next, and select the version of Exchange you are using, as you can see, it supports all versions from 2000 through 2010:

Click next, and it will ask you if you want to publish a single site, or multiple sites for load balancing. In this example, since we only have one CAS server, we’ll select Publish a single Web Site or Load Balancer:

Click Next. The next screen is how you want the TMG server to speak to the CAS server. Since security is paramount here, we want to select “Use SSL”.

Click next, and now it will ask for the Internal Site Name. This is the DNS name of the internal CAS server. Since the TMG server is also on the local LAN, this would be the INTERNAL DNS NAME of the server, or in our example, NYCAS01.internal.local

Click next, and this screen is asking what EXTERNAL DNS NAMES your users will be typing into their browsers to connect to this page from an external computer. If you set the public name wrong, users won’t be able to connect. In our example, users will type in owa.company.com to access the OWA page from outside the organization.

Next, we have to select a Web Listener. Since we haven’t created on, there are none from the drop down:

Select “New” and we’ll be presented with the New Web Listener Wizard

After creating a name, select next, and you’ll be presented with should the listener require SSL. Since, again, security is paramount, we select require.

Next, it will ask what networks will be connecting to the server through this listener; here select External since this will be a web page that users will access from outside the company network.

Next, you’ll need to select the SSL certificate to use to secure this connection. Select the certificate we imported earlier:

Next, we are selecting particulars of how the user will log in through this listener. Here, we want to select HTML Form Authentication, and we need to select Collect Additional Delegation Credentials in the Form, and select RSA SecurID. This will add an extra field in the OWA logon page, requesting the SecureID token from the user’s key fob.

At the next screen, uncheck the option for Single Sign On:

At the next screen, you’ll get prompted with the following screen:

Select Yes. The TMG server has built in RSA dll’s, so you don’t need to install the RSA Agent software on the TMG server. You do need to select yes though here, to create the necessary firewall rules to enable communication between the TMG server and the RSA server.

Now, you’ll be returned to the Exchange Publishing Rule Wizard, and the Web Listener should be populated with the new Web Listener you just created:

At the next screen, you are presented with how the TMG server is going to authenticate to NYCAS01. Here, we are going to select Basic Authentication. Since it’s wrapped in an SSL wrapper, Basic Authentication in this case is secure:

The next screen will allow you to select which users can authenticate through this connection:

We’ll leave All Authenticated Users and select next. This will finish the creation of the rule. Ensure you hit apply at the top of the Firewall Page to apply the changes made:

So that takes care of the configuration on the TMG server side, but we need to ensure of some configuration on the Client Access Server side of NYCAS01.

On NYCAS01, open the Exchange Management Console, and Browse to Server Configuration->Client Access Server->NYCAS01 and right click the OWA virtual directory and select properties:

Remember, before we selected Basic Authentication as the method the TMG server would use to authenticate to NYCAS01, so ensure this is selected as an authentication option. After you apply these settings, you’ll need to run IISRESET /NOFORCE from a command line to recycle the IIS process and apply the changes.

So, now we should be all set, let’s test it out! If we point our browser to the external IP of the TMG server we should be presented with the correct logon page:

There we go! Notice the three boxes, one for user name, password and pass code.

One more thing. Remember before, how I warned you that if you didn’t copy the sdconfig.rec file to C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig you would receive an error? The error is actually received by the end user, as a web server busy message as below:

Just copy the file to correct location, no need to recycle services, and you should be all set!

Any questions just shoot me an email!

How to Manage a Datacenter Failure or Disaster Recovery Scenario in Exchange 2010 – Part 3

Exchange 2010, High Availability

In Part 3 of this series, we are going to discuss how to failback to your primary site, after whatever condition that caused it to go offline in the first place occurred.

So when we last left off, we have activated all of our databases in our disaster recovery site. I showed you how had to stop the mailbox servers in the primary active directory site, which then allowed us to activate our disaster recovery site.

So now, let’s say the flood that occurred in the New York site has been fixed, all the water’s been removed, and thankfully, it did not damage our equipment. We are ready to move everything back to NYC. We begin by powering on the servers in NY. Since our DAG is in DAC mode, the NY servers do not try to mount their copies of the databases. Instead, the begin copying over any log files so as to bring their copies of the databases up to date with the DR site. Wait until all the database’s are reporting a status of healthy:

Now, remember, we told the DAG that the NY servers were down with the Stop-DatabaseAvailabilityGroup command from Part 2:

Notice how NYMB01 and NYMB02 are both listed as Stopped Mailbox Servers. You will get this error in the console if you try to activate the database on one of those two servers:

What we have to do is start these servers in the DAG, making them viable copies for activation again. We do this with the Start-DatabaseAvailabilityGroup command. Again, we could use with the –MailboxServer command and specify each server, separating them with a comma, or we can specify the whole site with the –ActiveDirectorySite option as below:

Start-DatabaseAvailabilityGroup DAG1 –ActiveDirectorySite NYC

Now if we run the Get-DatabaseAvailabilityGroup command, all servers are listed as started

Now, Microsoft recommends dismounting the databases that are going to be moved back to the primary datacenter site. This will mean that you will need to get a maintenance window to perform this action, as the databases will be offline. Keep in mind that you do not NEED to dismount the databases; it is just recommended by Microsoft.

Now, we can activate the Database. You can do this either by using the shell with the Move-ActiveMailboxDatabase MDB01 –ActivateOnServer NYMB02 command:

Or through the EMC with the Activate a Database Copy Wizard:

Now, the database should be activated. One issue that I have seen pop up is that the Catalog Index is corrupted. This is the index for the Full Text Index Search. If this is the case, you may have to reseed the Catalog Index with the following command:

Update-MailboxDatabaseCopy MDB02NYMB02 –SourceServer DRMB01 –CatalogOnly

This command will reseed the content index from the server DRMB01. You should now be able to activate the database copy.

Continue by moving all active database copies to their respective servers. If you dismounted the databases as stated above, now mount these databases.

Now, our clients are still connected, but they are still connecting through DRHT01.nygiants.com because it is set as the RpcClientAccessServer:

17-Dec09 15.08

We simply need to run the command Get-MailboxDatabase | Set-MailboxDatabase –RpcClientAccessServer NYHT01.nygiants.com to change this setting over:

If we check the properties of the databases, we see that NYHT01.nygiants.com is again set as the Rpc Client Access server:

Now, our Outlook clients will be connecting through NYHT01 for their access:

Well, that’s it!

In this three part series, I should you how to activate the backup datacenter, in the event that the primary datacenter became unavailable. We discussed the theory behind the process, mainly Datacenter Activation Coordinator, the actual work needed to do it, as well as how to failback when the primary site came back online.

If you have any questions, feel free to email me at ponzekap2 at gmail dot com.

How to Manage a Datacenter Failure or Disaster Recovery Scenario in Exchange 2010 – Part 2

Exchange 2010, High Availability

 

In the first article of this series, we went over some of the premises of Exchange 2010, Database Availability Groups or DAG’s, and Database Activation Coordinator.  We discussed our test environment, as well as how, in theory, an Exchange 2010 DAG handles the failure of a datacenter.

In this article, I’ll show you how to actual activate your disaster recovery site, should your primary site go down.

One of the first thing’s we need to take into consideration is how the clients, most importantly Outlook, connect to the DAG.  We spoke in the first article how there is a new service in Exchange 2010 Client Access Servers, called the Microsoft Exchange RPC Client Access Service.  Outlook clients now connect to the Client Access Server, and the Client Access Server connects to the Mailbox Server.  This means Outlook clients don’t connect directly to the Mailbox Server’s anymore.  This becomes significant in a disaster recovery situation.  

Lets look at the output of the command:

Get-MailboxDatabase | Select Name,*rpc*

09-Dec02 18.20 

The RpcClientAccessServer value on a particular Mailbox Database indicates that connections to this database, are passed through to the Client Access Server listed.  So, for all these databases above, all Outlook connections have to go through NYHT01.nygiants.com.  (If you have more than one Client Access Server per site, which you should for redundancy and load balancing, you can create a cluster using either Windows Network Load Balancing, or a hardware load balancer, and change this value to point to the cluster host name).  Lets look at our Outlook Client, and we notice that all connections are being passed to NYHT01.nygiants.com:

09-Dec03 18.23

Alright, now, we are ready to start failing over servers!  My test user, Paul Ponzeka, is located on a mailbox database named MDB02 which is running on server NYMB02:

09-Dec04 18.27

So, to simulate a datacenter failure, we’ll just pull the power on ALL NY servers:

NYDC01

NYHT01

NYMB01

NYMB02

NY-XP1 (client machine)

So now, all of our NY machines are off, lets check the status of the Databases on our DR servers located in Boston:

09-Dec05 18.40

Well, that’s not good huh?  Notice how the DB’s for the two copies in NY are listed as ServiceDown under copy status?  Also note that DRMB01, the Mailbox Server in Boston’s copy of the database is Disconnected and Healthy.  The reason the DB is not mounted, is because of the DAC mode enabled on the DAG, which we discussed in Part 1 of this series. DRMB01 dismounts ALL its Mailbox Databases because there are not a majority number of DAG members available, this it can’t make quorum. It dismounts to prevent a possible split brain scenario, but in this case, we REALLY need to get this activated.  How do we do this?  What we need to do is remove the NY server members as being active participating members of the DAG.  We do this through the Exchange Shell.

If we note the current status of the DAG with the command:

Get-DatabaseAvailabilityGroup | select Name,*server*

09-Dec06 18.47

Notice that the Servers value lists DRMB01, NYMB01 and NYMB02 has servers in the DAG, and lists them again as StartedMailboxServers?  Well, we need to tell the DAG, that NYMB01 and NYMB02 are no longer “started” or operational.  We need to use the following command for that:

Stop-DatabaseAvailabilityGroup.

Our command can specify each server that’s down, one by one:

Stop-DatabaseAvailabilityGroup –Identity DAG1 –MailboxServer NYMB01,NYMB02

Or, since we lost the entire NY site, we can specify that the entire NY site:

Stop-DatabaseAvailabilityGroup –Identity DAG1 – ActiveDirectorySite NYC

Now, since our Mailbox Servers in NY are actually unreachable, we want to specify the –ConfigurationOnly option at the end of this command.  Otherwise, the command attempts to actually stop the mailbox services on every mailbox server in the NYC site, and causes the command to take an extremely long time to complete:

09-Dec07 18.55

Now, if we re-run the command:

Get-DatabaseAvailabilityGroup | select Name,*server*

09-Dec08 18.56

We notice that the NY mailbox servers, NYMB01 and NYMB02 are both now listed as Stopped Mailbox Servers.

Next, ensure that the clustering service is stopped on DRMB01:

09-Dec09 18.57

Now, we want to tell the DR site, it should restart with the new settings (both the NY servers missing):

Restore-DatabaseAvailabilityGroup –Identity DAG1 –ActiveDirectorySite DR

09-Dec10 18.59

You will see a progress bar, indicating its adjusting Quorum and the cluster for the new settings.  Don’t be alarmed if you see an error regarding the command not being able to contact the downed mailbox servers.

If we return to the Exchange Management Console, all our databases in the DAG have been mounted on DRMB01!

09-Dec11 19.01

Great right?  But our clients are still having trouble connecting.  What’s the problem?

09-Dec12 19.02

The reason is that NYHT01.nygiants.com is still listed as the RPC Client Access Server for this database:

09-Dec13 19.05

We have two choices.  First, is to change the DNS record for NYHT01.nygiants.com to be a CNAME for DRHT01.nygiants.com.  Or the second, and faster method, is changing the RPC Client Access Server to be DRHT01.nygiants.com with the following command:

Set-MailboxDatabase MDB02 –RpcClientAccessServer DRHT01.nygiants.com

09-Dec14 19.07

To do it for every DB that you failed over is simple:

10-Dec01 08.54

Now, back to the Outlook client and WHOILA!

09-Dec17 19.11

Now all your messaging services are back and running in your Disaster Recovery site, with limited downtime for your end users.

In this article we discussed how to fail over a datacenter to your backup or disaster recovery datacenter, should your primary go offline.

In the next and final part of this series, I’ll show you have to fail back to the primary datacenter site, which some admins think is even more terrifying than failing over!

Stay Tuned!

How to Manage a Datacenter Failure or Disaster Recovery Scenario in Exchange 2010 – Part 1

Exchange 2010, High Availability

 

Exchange 2010 introduced several high availability and disaster recovery features, the one that receives the most publicity is the Database Availability Group (or DAG for short) feature.  In short a DAG allows replication of a mailbox, to other servers in the DAG, that can be activated automatically within 30 seconds, restoring user access to their mailbox’s.  For more information see my article series on DAG’s here.

The automatic failover is great for High Availability within a datacenter, or even across a datacenter.  For instance, consider the following diagram:

DB

Here, the green copies are the Active Copy, they are the one’s users are actually accessing for their mailbox’s.  The yellow and the red are copies that can be activated, should the Active Copy go offline.  Consider the possibility that MDB01 on server NYMB01 goes offline, the copy on NYMB02 would be activated within 30 seconds automatically.  Next, the drive holding the database MDB01 on server NYMB02 fails, causing THIS copy to go online.  In this case, the copy of MDB01 on DRMB01 in Boston would be activated with 30 seconds, and users would be able to access their mailbox’s, across the WAN link to Boston!  This is all part of the design of the DAG, and is great from a High Availability standpoint. 

But, as we know, High Availability and Disaster Recovery are COMPLETELY separate.  High Availability means to provide your users with high uptime, or access to the application.  Disaster Recovery is the ability of the application to function when a catastrophic event happens, such as destruction of a datacenter or worse, the building holding the datacenter.  This last part, is what we will cover in these articles.  To do so, there is a feature of DAG’s that we need to talk about, and that is the Datacenter Activation Coordinator, or DAC.

DAC is a setting on a DAG that has three or more member mailbox servers, that are extended to multiple sites.  So, a higher level view of our Exchange environment is below:

How to Manage a Datacenter Failure 2010

NYMB01, NYMB02 and DRMB01 are all part of the same DAG, lets call it DAG1, and all these servers are located in the NYGIANTS.COM domain.

Now, our DAG fits the criteria for DAC mode, which is three or more member servers, spread across multiple Active Directory Sites.  So, now what is DAC mode?

DAC mode is, quite simply, a mechanism to prevent the possibility of a split brain in your exchange environment.  Consider the following scenario.  As per the first diagram, you have MDB01 and MDB02, and both active copies run in NY on NYMB01 and NYMB02 respectively.  NYHT01 is running the file share witness.  A file share witness is a server that only participates if the DAG has an even number of servers, it’s used to “break” any tie in voting regarding if a server is down or not.  The NY site is connected via WAN connection to Boston, where DRMB01 hosts replica’s of MDB01 and MDB02.  Say there is a cut to the WAN connection, and for whatever reason, NY and Boston can no longer communicate, but neither side is truly offline.  The Boston side, since it can no longer connect to the NY server’s, assumes they are down, and mounts the database copies it has of MDB01 and MDB02, and marks them as active.  Since NY is still operational, it STILL has its copies of MDB01 and MDB02 mounted and active.  This is a split brain scenario, both sites believe that they are the rightful owner of the database, and have thus mounted their respective DB’s.  This would cause a divergence in data.  For example, if outside user, sends an email to a user at nygiants.com, and its received in NY, it would get delivered to his mailbox in NY.  If another user sends the same user at nygiants.com an email, and it gets received by Boston, it would get delivered to that’s users mailbox in Boston.  Each mailbox is different, which is a huge problem, this is the issue with a split brain scenario, and is what DAC was built to protect against. 

DAC does this by preventing the DR servers from mounting their databases.  DAC requires that a majority set of the DAG members be available for the DAG to be able to make an operational decision, in this case the DR servers mounting their database.  A DAG that has the majority of its member servers is said to have Quorum.  So, in our previous example where the line was severed, DR would NOT mount its database’s.  Why not?  Because the DAG consisted of 3 total members, NYMB01, NYMB02 and DRMB01.  What this means is that according to DRMB01, its the only surviving server, which is 1 out of 3, and is not a majority, hence it cannot mount its database. Now, if you look at the first diagram, you will notice that MDB03, is green on DRMB01, meaning that the active copy of MDB03 is running on DRMB01.  Well, what happens in this scenario, where the WAN connection was cut?  Wont one of the NY servers mount MDB03?  Since DRMB01 has MDB03 already mounted, wont this cause the EXACT split brain scenario we are trying to avoid?  No.  Why not?  Remember how I said that the DAG needs to be able to make Quorum?  Well, in this case, since DRMB01 cannot make Quorum, it is forced to dismount any database that it has running.  In the event log, you’ll see the following message:

02-Dec10 19.43

So, DRMB01 dismounts MDB03, which is mounted and activated in NY.  This is how the split brain scenario is avoided. 

So what does this mean if there really is a need for a datacenter failover?  At one site I work at, there was a broken pipe in the tenant above them, causing a flood that threatened to destroy their datacenter.  If the datacenter had been destroyed, how do we activate DR?  We’ll go over that in Part 2 of this series.

For this article, we discussed mainly the theory and thought process behind DAG’s, Datacenter Activation Coordinator, and the concept of Quorum with regards to the cluster. In the next article, we’ll jump in and do an actual datacenter failover. 

How to Apply Permissions to Public Folder and All Sub Folders in Exchange 2007/2010 Using Exchange Management Shell

exchange 2007, Exchange 2010, Public Folders

 

If you have a public folder that your working on, and you need to apply permissions to it using the Exchange Management Shell, its pretty easy.  The command is:

Add-PublicFolderClientPermission –Identity “Foldername” –user UserName –AccessRights PublishingEditor

For instance, to add the user pponzeka to the folder IT with the Publishing Editor permission, the command would be the following:

13-Nov01 11.12

This works great, but what if we have several subfolders under IT, and we want to apply the same user permissions to all of the subfolders as well?  A utility called PFDAVADMIN that was available from Microsoft used to allow you to do this, and it still works with Exchange 2007.  But, since the protocol it uses, WebDAV is no longer available in Exchange 2010, we no longer have this option.  Plus, the shell is easier to use anyway!

So, we have the IT public folder, and three subfolders:

13-Nov02 11.16

So, first, in the Exchange Management Shell, if we attempt to list the public folder IT, this is the result of what we’ll see.  The command used is Get-PublicFolder –Identity “IT”

13-Nov03 11.21

That’s odd, we know there are three folders underneath, why doesn’t it list these?  We need to add the –Recurse option to our command, so that it looks in the root, and everything underneath.  So the command should be Get-PublicFolder –Identity “IT” –Recurse

13-Nov04 11.23

Notice the Parent Path?  IT has listed, which means its a Top Level Folder in Public Folders.  The other three have IT listed, which means they are sub folders of IT.

So, back to the top.  The permission to add permission on a public folder was:

Add-PublicFolderClientPermission –Identity “Foldername” –user UserName –AccessRights PublishingEditor

So in our case it was:

Add-PublicFolderClientPermission –Identity “IT” –User pponzeka –AccessRights PublishingEditor

So, now, how do we apply these permissions to the root folder, in this case IT, and all three subfolders, in this case Documents, Emails and Plans?  Well, we use the piping command to pipe the entire list of folders to the Add-PublicFolderClientPermission command.

Get-PublicFolder –Identity “IT” –Recurse | Add-PublicFolderClientPermission –User pponzeka –AccessRights PublishingEditor

13-Nov05 11.30

Note that we don’t need to specify the Identity  in the Add-PublicFolderClientPermission because we piped that to it with the | command.

And there you go.  The user account has been given these rights to the root folder, IT, and all its subfolders.  This works for any number of subfolders, and you can also use the same method to remove access rights. 

Exchange 2010 Archive Mailbox and Retention Policies – Part 1

Exchange 2010

**UPDATE**

Part 2 Available Here – http://port25guy.com/2014/10/22/exchange-2010-archive-mailbox-and-retention-policiespart-2/

Also, after Exchange 2010 SP1, archive mailboxes can be placed in a separate database.

 

**End of Update**

PST’s and Mailbox Limits.  Those two items keep Exchange Administrator’s up at nights.  One of the biggest battles between the end users and the administrator is mailbox size and retention.  It’s pretty well known that the bigger the mailbox get’s, usually the worse the performance gets.  Admins have been trying for years to get users to get their mailbox size down, and users always fight back.  With the dramatic changes that the Exchange Team has made to the Mailbox Store in Exchange 2010, it is now possible to have huge mailboxes’ (10GB+) to support the growing need’s of our end users.

Problem is, we still want to get the best performance possible out of our mailbox’s.  For archive purposes, the only “built in” solution from Microsoft was to export data to PST files.  PST files though are not managed by the organization, are prone to corruption, not accessible through OWA, and are generally messy.  Company’s were forced to move towards 3rd party utilities to satisfy their archiving and compliance needs.

One of the new features in Exchange 2010 is the Archive Mailbox feature.  Simply put, the Archive Mailbox is an extra mailbox assigned to the user, that’s meant to hold older, less accessed data.  For instance a user could place every email older than 1 year in the archive folder, keeping only new constantly accessed data in the primary mailbox.  The Archive Mailbox is integrated into the users Outlook Profile in Outlook 2010:

28-Aug05 15.43

As well as Outlook Web App (the new name for Outlook Web Access in Exchange 2010):

28-Aug06 15.44

There are some caveat’s to the Archive Mailbox feature:

  1. Only Outlook 2010 supports the integration of the Archive Mailbox in the user profile
  2. The archive mailbox is placed in the SAME database as the primary mailbox

Word on the street is that Microsoft is working on a plug in or an update to Outlook 2007 that will allow the older version of Outlook to access the Archive Mailbox.  Still, many companies have an Office 2003 installation that will be hard to uproot to 2010 for this feature.

The second point I think is the one that really hurts this feature.  The fact that the archive mailbox is part of the same database as the primary mailbox.  I understand that in 2010, the IOPS requirement has been dramatically lowered, and now the organization can run on SATA or Tier-2 disk’s, but many company’s want to segregate their data onto different tier’s and speed of storage.  I think this aspect of the feature will end up hurting Microsoft.  Let’s see if they make a change in the future.

I digress.  The Archive Mailbox is essentially meant to replace the use of PST’s.  The best part is you can drag data from existing PST’s into the archive, just like you can drag messages from your inbox to the archive.  But the real power is setting this up to be done with policy’s, called Retention Policy’s.

As administrator’s, we can control the length of time that users are allowed to keep items in their primary mailbox.  This is an extension of the Management Folder’s feature from Exchange 2007.  In 2007 however, users had to place email’s in certain folder’s, be it inbox, or a created folder, so that the policy’s were enacted properly.  2010 uses the concept of Retention Policy’s as well as Retention Policy Tag’s to enforce these settings.

Retention Policy Tag’s are classification’s that are set for a folder or a type of item.  For instance you can create a Retention Policy Tag for the inbox, and set it to archive anything over 90 days.  You could also set a Retention Policy Tag for any calendar item over 180 days to delete and not archive.

You would then group this tag’s into a Retention Policy, which would then be applied to a mailbox.

By default, Exchange 2010 comes with two retention policy’s, Default Archive Policy, and Arbitration.

The Default Archive Policy comes with predefined tags:

  1. Personal never move to archive
  2. Personal 1 year move to archive
  3. Personal 5 year move to archive
  4. Default 2 year move to archive

You can check these settings by entering the following powershell command:

Get-RetentionPolicy *default* | fl

31-Aug01 10.19

Every mailbox that is archive enabled is automatically assigned the default retention policy.  You can determine the retention policy by running the command Get-Mailbox jsmith | select Name,RetentionPolicy:

31-Aug02 10.22

So according to the Default Archive Policy, the user can tag items as one of the three personal setting’s, and then have it moved to archive after the specified time, and anything not tagged will be moved to the archive after 2 years.  Retention Policy’s base the time or age of the message on when the item was delivered, or if the item wasn’t delivered (such as calendar item or post), when the item was created.

The Arbitration Retention Policy is used for moderated mailboxes.  Moderated mailboxes are used for users who mail must pass through a manager for approval first, or for group membership approval.  This policy should only be used in conjunction with these type of mailboxes.

Next, we’ll create a user and assign him an Archive Mailbox

Creating the user is straightforward and exactly the same as normally creating a mailbox, except for one thing.  Towards the end of the mailbox creation period, you’ll be prompted with this screen:

28-Aug07 16.32

You can create an archive mailbox at the mailbox creation time, or after the mailbox is created by right clicking the user and selecting

28-Aug08 16.39

One thing to keep in mind is you cannot mix Retention Policy’s and Managed Folder Mailbox Policy’s.

Notice how the icon changes for Archive Enabled mailbox’s:

28-Aug09 16.43

If we navigate to the each user in ADSIEDIT, you’ll see some other difference’s in available attributes.  The three in particular are msExchArchiveGuid, msexchArchiveName, and msExchMailboxtemplateLink.

28-Aug10 16.47

Notice how the user on the right the value’s are blank, and how they are populated on the John Smith user on the left.  Also, notice the msEchMailboxTemplateLink value.  This is the retention policy applied to this particular user.

In this first part, we discussed the new Online Archive Mailbox feature of Exchange 2010, its concept and purpose, and then discussed how administrator’s can apply them using Retention Policy’s.  In part two of this article.  We’ll get in and get our hands dirty, and start applying policies, and seeing how Exchange manages and move’s item’s accordingly.

Uncovering the New Move Request Feature in Exchange 2010

Exchange 2010

 

One of the biggest issue’s any administrator faces with any type of Exchange upgrade or migration is the prospect of mailbox moves.  The issue comes from the fact that a mailbox move, from the moment it’s started, makes the mailbox unavailable to the end user until it’s completed.

This comes from the way that mailbox moves are done in Exchange 2000/3/7.  The mailbox move is actually a MAPI copy operation.  The reason’s behind this are clear, Exchange need’s to lock in the mailbox, then copy it, to ensure that no data is lost. The user is stuck waiting for the mailbox move to complete, meaning they can’t work.  This ends up in mailbox moves being forced to happen late at night in bunches, through the use of scripting or other methods. 

One of the exciting new features of Exchange 2010 is online mailbox move’s, which are called Mailbox Move Requests.  This new feature allows administrators to move mailbox’s while the user is actively using it.  How does this work you ask?  The magic lies in a new service that is installed on Exchange 2010 Client Access Servers, the Microsoft Exchange Mailbox Replication Service:

27-Aug01 15.37 

Exchange 2010 no longer performs a MAPI copy operation to perform any of it’s mailbox moves.  Now, when a move request is created, the Microsoft Exchange Mailbox Replication Service or (MRS) is responsible for replicating the mailbox from it’s source, to it’s destination. An initial replication occurs, and then incremental updates happen until the service can complete the move.  Once the service completes’ the sync, the user receives a message to restart outlook.  They restart, their mailbox is again available.  The only downtime was for them to restart Outlook, not bad at all.

The nice part about this, is that mailbox move’s from Exchange 2007 benefit from this feature when moving to an Exchange 2010 mailbox.  Keep in mind that you must be at service pack level 2 with Exchange 2007 for it and 2010 to interoperate.

Let’s take a look at actually performing one of these.  In our environment we have two Exchange 2007 servers, DEVLOCALHT1, which is a Hub Transport/Client Access Server, and DEVLOCALMB1, which is a Mailbox Server.  Then we have three Exchange 2010 servers.  DEVLOCALHT2010, which is a Hub Transport/Client Access Server, and then DEVLOCALNODE1 and DEVLOCALNODE2 which are both Mailbox Servers.  The Mailbox Servers are joined into a Database Availability Group or DAG.  If your not sure what a DAG is, see my article series:

DAG – Part1

DAG – Part2

DAG – Part 3

DAG – Part 4

Our user, creatively named Paul Ponzeka, has an Exchange 2010 mailbox. We currently have two Mailbox Database’s in Exchange 2010, MDB1 and MDB2:

27-Aug03 16.08

Currently Paul Ponzeka’s mailbox is located on MDB1, and we’ll move him to MDB2.  In the Exchange 2010 EMC, navigate to Recipient Configuration->Mailbox.  Select Paul Ponzeka, right click and select New Local Move Request:

27-Aug15 16.32

Don’t let the language fool you, if your moving a mailbox anywhere within the SAME Active Directory Forest, its a Local Move.  If your moving the mailbox Cross-Forest’s, its a Remove Move.

Select the target mailbox database:

27-Aug16 16.32

After selecting next, you’ll see a familiar screen regarding what to do regarding corrupted items.  You can choose to have the move fail, or to ignore up to a certain amount of items.

27-Aug06 16.13

After you select next, you’ll have a summary page, select the “New” button, and as always, it will provide you with the powershell command for the equivalent.

27-Aug17 16.33

Now, if you navigate to Recipient Configuration->Move Request, you’ll see the move request, and it’s progress:

27-Aug18 16.33

You can also get the progress through the Exchange Management Shell by running the command:

Get-MoveRequest

27-Aug19 16.34

Also, in the Event Viewer of DEVLOCALHT2010, the Client Access Server handling the move, we will note that Event ID 1102 is logged regarding the start of the move:

27-Aug20 16.34

Once the move is complete, Event ID 1107 will be logged:

27-Aug21 16.37

And if we notice back in the EMC, the status of the move:

27-Aug22 16.38

And the shell:

27-Aug23 16.38

Now, the client, who’s Outlook has been open the whole time, will receive the following message:

27-Aug14 16.22

Once the client restart’s outlook, their mailbox is back, and they’ve only been out of Outlook from the time the move completed, till when they restart.

The move’s work EXACTLY the same way as from an Exchange 2007 SP2 mailbox with no difference. 

The new online mailbox moves, through the Move Mailbox Request feature of Exchange 2010 will allow administrators to move mailbox’s with minimal downtime and interruption to the end users.