Elan Shudnow’s Blog

Exchange 2010 introduced the ability to move your personal archive mailbox to a separate mailbox database. This was a common request due to the limitations in Exchange 2010 RTM where the personal archive mailbox would be housed on the same database as the user mailbox.  This would of course limit the ability to use a tiered storage model.

In order to move the personal archive mailbox, we would need to ensure both the user mailbox as well as the archive mailbox are on SP1.  So if you are in a multi-server environment where some mailbox servers are RTM and SP1 and you have moved the user to SP1 and want to then split off the personal archive mailbox to a separate database, make sure that server that you move the personal archive mailbox to contains SP1. Should you decide to move the mailbox back to RTM, you must move both the user mailbox and the personal archive both to an RTM Server.

So let’s go through two scenarios.  The first, we will move an existing user’s personal archive to a separate database.  The second scenario we will create a new user with a personal archive and have the personal archive live on a separate database.

Important: Please keep in mind that the screenshots below SP1 Beta softwareand even the statement about Microsoft Support are not final as this article is based off of SP1 Beta software and may change by the time Exchange 2010 SP1 ships.

Scenario 1 – Moving an existing Personal Archive Mailbox to a Separate Database

So let’s take a look at a test mailbox I created, Frodo Baggins. We can see that both the user mailbox as well as the personal archive mailbox live on the same database.

So let’s move the personal archive to a separate database, MDB2.

To check the status of the Move Request, we can run the following command:

Now that we see the move has been Completed, we can check again to see what mailbox our user mailbox and our personal archive mailbox are located on. As you will see, our user mailbox and our personal archive will be housed on separate databases.

Let’s say we want to then move the Personal Archive Mailbox to MDB1.  But this time, let’s use the Exchange Management Console. We can see the existing database that both the User Mailbox and the Personal Archive Mailbox lives on.  We can also choose to move only the Personal Archive Mailbox.  We will choose MDB1.

We will then go ahead and verify again that the personal archive has successfully been moved to MDB1.

Scenario 2 – Creating a new User and separating their user mailbox and personal archive mailbox to separate databases

Microsoft has also updated the GUI so that when you create a new user, you can specify what database the user mailbox will live on as well as what database the personal archive mailbox will live on.  Let’s go ahead and create a new Active Directory user and assign this user an Exchange Mailbox as well as a Personal Archive Mailbox.

We will specify the User Mailbox to live on MDB3.

We will specify the Personal Archive Mailbox to live on MDB2 which is different from the User Mailbox which will live on MDB3.

We can then verify in the Exchange Management Shell to see if our User Mailbox is properly in MDB3 while our Personal Archive Mailbox is in MDB2.

A note about Microsoft Support

One important thing to note, is that in order to have support for personal archive mailboxes being on separate databases, both mailbox databases must be located within the same Active Directory Site.  The only time a personal archive will be supported on a database in a separate Active Directory Site is during a failover scenario where the database copy fails and activates on a separate server located in a separate Active Directory site.  But for normal operations, the user mailbox and personal archive mailbox database should be in the same Active Directory Site.

Elan Shudnow :: Apr.07.2010 :: Exchange, Exchange 2010 :: 172614 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F04%2F07%2Fexchange-2010-sp1-personal-archive-mailboxes-on-separate-databases%2FExchange+2010+SP1+Personal+Archive+Mailboxes+on+Separate+Databases2010-04-08+02%3A14%3A45Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1726

With Exchange 2010 comes many advantages in the HA realm.  One of them is the ability to connect to the Client Access Server for RPC.  This means, when a Mailbox Server does a *over (failover or a switchover), the user is still connected to their RPC Endpoint.  You can also create a Client Access Array which load balances your RPC Endpoint on your CAS Servers.  Lots of information on the RPC Client Access Server here and here.  So what options are available for load balancing this new RPC Client Access Array and at the same time, load balancing all our other services?  And what are the pros/cons of each method?  If you want to know, read on…

Exchange Load Balancing Options

In Exchange 2007, if you wanted any type of HA, you needed at least four servers.  2 for CCR Nodes and 2 for HUB/CAS Nodes.  The reason why you cannot have 2 nodes altogether is that CCR Nodes were limited to the Mailbox role only.  For an Exchange Site, you need to always have at least the  HUB/CAS/MBX Role  for that site to be operational.  In Exchange 2010, more options are now available.  You now have something called Database Availability Groups (DAGs).  These DAG members can contain all Exchange roles (HUB/CAS/MBX/UM) but still may not contain the Edge Transport role.

There is a problem though.  There is a Windows limitation that allows you to install Windows Network Load Balancing on a server that also contains Failover Clustering Services. So while we can now have 2 Exchange 2010 Servers, we need a way to load balance the CAS role to provide High Availability for the following CAS Services:

• Outlook Web App (formerly Outlook Web Access) (HTTP Traffic)
• Exchange Control Panel (HTTP Traffic)
• Exchange Web Services (HTTP Traffic)
• Exchange ActiveSync (HTTP Traffic)
• Autodiscover (HTTP Traffic)
• Offline Address Book (HTTP Traffic)
• Outlook Anywhere (HTTP Traffic)
• RPC Client Access (RPC  Traffic)

There are a few options for load balancing.  The first is the ability to use ISA.  The problem here, is that ISA can only load balance HTTP-based traffic.  If you take a look at the bulleted list above, you can see that RPC Client Access Service is RPC Traffic which means that ISA cannot load balance this traffic.  We have a few load balancing options then:

1. 2 Multi-Role DAG Members and Hardware Load Balancers – Utilize 2 Multi-Role DAG Members (MBX/HUB/CAS).  Use a hardware load balancer to load balance all of the bulleted items above including the RPC Client Access Service using an RPC Client Access Array which load balances port 135 for the RPC Endpoint Mapper and 1024-65535 ports.  Typically, since you are using High Availability, this means that you would most likely want to have 2 hardware load balancers.



2. 2 DAG Members, 2 HUB/CAS Servers, and Windows Network Load Balancing - Utilize 2 DAG Members (MBX).  Use 2 HUB/CAS Servers with Windows Network Load Balancing.  Windows Network Load Balancing will load balance all of the bulleted items above including the RPC Client Access Service using an RPC Client Access Array which load balances port 135 for the RPC Endpoint Mapper and 1024-65535 ports.



3. 2 DAG Members and DNS Round Robin - Use 2 Multi-Role DAG Members (MBX/HUB/CAS).  Use DNS Round Robin to achieve a “poor man’s solution” type of load balancing.  With this scenario, you will not have automatic failover for the RPC Client Access Service.  You will essentially create two A Record for the RPC Client Access Array; one pointing to the first multi-role DAG Member and one pointing to the second multi-role DAG Member.  You will most likely want to lower the TTL values of these DNS records to 5 minutes so if a failure does happen, you can remove one of the A records and the clients will flush their DNS cache within 5 minutes time.



4. 2 DAG Members, ISA/TMG/UAG, and either Hardware Load Balancing or DNS Round Robin - Use 2 Multi-Role DAG Members (MBX/HUB/CAS).  Use ISA/TMG/UAB to load balance all HTTP items from the bulleted list above. The issue here is that now with Exchange 2010, for mailbox access, users connect to the Client Access Server for their RPC Endpoint.  To make this redundant, we create an RPC Client Access Array.  This RPC Client Access Array can be load balanced through a hardware load balancer, DNS Round Robin, or Windows Network Load Balancing.  ISA/TMG/UAG cannot load balance non-HTTP Traffic.  So if you have ISA/TMG/UAG, you can still use it to load balance all HTTP Traffic but you would still need to use a Hardware Load Balancer, DNS Round Robin, or Windows Network Load Balance to load balance the RPC Client Access Array.  The example picture below will show the use of UAG with a Hardware Load Balance mix.

Exchange Load Balancing Options and their benefits

Taking a look at the above list of options, we can use several different options including Windows Network Load Balancing, Hardware Load Balancing, and DNS Round Robin. Each has their pros and cons in terms of cost and functionality.

Hardware Load Balancing

Hardware Load Balancers can have the most capacity in terms of user connections.  But for SMBs, you won’t have to worry about load.  The load is more for very large organizations.  In fact, Microsoft recommends that if you are going to require over 7 HUB/CAS Servers in a load balanced farm, to use Hardware Load Balancers instead of Windows Network Load Balancing.  Hardware Load Balancers are also the most expensive option.

Hardware Load Balancers do have the best functionality from a perspective of Client to Server Affinity depending on the vendor used.  For example, we can use multiple affinities and have fallbacks to a specific affinity of our preferred affinity fails.  For example, we can set up up our hardware load balancers to use the following affinity in terms of preference:

• Existing Browser-Based Cookie
• Hardware Load Balanced created cookie
• SSL Session ID
• Source IP

The goal here is to make sure that every user is load balanced evenly and that automatic failover can occur quickly and smoothly.

Windows Network Load Balancers

Windows Network Load Balancers do not achieve as much capacity in terms of user connections as a Hardware Load Balancer, but they can still handle a lot of connections.  Windows Network Load Balanced farms can use as many as 8 CAS Servers without suffering a performance degradation.  In order to have the need for 8+ CAS Servers, you’ll need to have many users (tens of thousands). Windows Network Load Balancing is built into Windows Server and therefore, it’s a large cost savings in comparison to purchasing hardware load balancers.

Windows Network Load Balancers do not have as good of functionality of Hardware Load Balancers from a perspective of Client to Server Affinity.  For example, we only have one affinity method.  That method is Source IP.  The downside to using Source IP is if you have a lot of connections coming from a NAT’d Source IP. This means that all of these connections will end up hitting the same Client Access Server as again, the only Affinity Method a Windows Network Load Balancer has is Source IP.

Most likely, if you don’t have the need for more than 8 CAS Servers, Windows Network Load Balancing will suffice for you needs.  It’s cheap, comes with Windows, and does its job.

ISA Server, TMG, or UAG

ISA/TMG/UAG Servers to have more capabilities than Windows Network Load Balancers.  The one downside to them is that they cannot load balance RPC Traffic.  Because of that, you can still use ISA/TMG/UAG to load balance your HTTP traffic, but you’ll still need a Hardware Load Balancer or a Windows Network Load Balancer to load balance your RPC Client Access Array.

ISA/TMG/UAG do scale better than Windows Network Load Balancing but not as well as a Hardware Load Balancer.  ISA/TMG/UAG does not cost as much as a Hardware Load Balancer but is more expensive than Windows Network Load Balancing.  ISA/TMG/UAG also has the capability to do Load Balanced created cookies as well as Source IP Affinity depending on the protocol ISA/TMG/UAG is publishing.

Another upside to using ISA/TMG/UAG is that they can do pre-authentication.  This means that if a server goes down in which a client has affinity to, ISA/TMG/UAG still contains the authentication context of the user and automatically re-authenticates to the new Client Access Server.

DNS Round Robin

DNS Round Robin scales just as high as Hardware Load Balancers because the connections will just go directly to the Client Access Servers.  If anything, it has the highest scale as you don’t have anything in the middle doing anything with the connections.  It’s also free to use!  But in this case, free is not necessarily good because you lose a lot of functionality.  Hardware Load Balancers, Windows Network Load Balancers, and ISA/TMG/UAG all have the capability to detect server failures and automatically stop sending to the server and direct all traffic to a server that is operational.

DNS Round Robin has no automatic server failure detection.  If a host goes down, an Administrator will need to realize it, remove the DNS A/HOST Record for the server that went down, and then clients will have to wait for the TTL value on the old DNS record to expire.  When that happens, the client will begin connecting to the proper server. So you save a lot of money going with this option, but you lose all automation and gain downtime instead.

Elan Shudnow :: Mar.17.2010 :: Exchange, Exchange 2010, ISA :: 168538 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F03%2F17%2Fexchange-2010-rtm-high-availability-load-balancing-options%2FExchange+2010+RTM+High+Availability+Load+Balancing+Options2010-03-18+04%3A30%3A02Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1685

A common question I see out there is if the RPC Client Access Service (including Client Access Service Arrays) can access databases in other sites. The answer is, yes. Let’s take a look at a couple scenarios.

Scenario #1 – Full Site Failure

Let’s say you have a Client Access Server Array called array.domain.com.  Primary Site goes down.  As a part of the manual site switchover process, you must update the DNS records in your Primary Site to point to the CAS infrastructure at your DR Site.  One out of several DNS records you change will include the CAS Array. You change array.domain.com to point to DRSiteCAS instead of PrimarySiteCAS.  The client (after the DNS record flushes – recommended for TTL value to be 5 minutes for DNS records in site resilient solutions) will then start to connect to the DRSiteCAS which will then access the database in the DR Site.

Scenario #2 – Server Failure(s) in Primary Site and Disabling Automatic Activation for Databases and Servers

In the case where all database copies go down in the Primary Site, your databases can automatically failover to the DR Site as long as you allow automatic activation on the DR Servers (yes, you can turn off automatic activation on databases and servers) and as long as you still have Majority for your Quorum. In this scenario, the RPC Client Access (and array) can access the mailbox databases that are mounted in the DR Site.

Automatic Activation

As I just eluded to above, it is possible to turn off automatic activation on databases and servers. There is something called Database Activation Policy.  Let’s say you wanted to disable a specific database from being considered in the Automatic Activation Process.

You can use the following command to prevent the database from being considered in the Automatic Activation Process:

This example resumes the copy of the database DB1 on the server MBX2 for automatic activation:

This is also possible to do at the mailbox server level using the Set-MailboxServer cmdlet.  You can use the following command to prevent any databases on a specific mailbox server from being considered in the Automatic Activation Process:

This example resumes all database copies on the mailbox server “MailboxServer” for automatic activation:

Example

Let’s say we have 6 DAG Servers with 4 in the Primary Site and 2 in the DR Site with no modifications to the Automatic Activation Policy (DAG Servers in the DR Site can automatically mount databases).  Let’s say, we currently have a lack of funds for storage which prohibit the ability to have mailbox database copies on all servers.  So PrimarySiteMBX01 and PrimarySiteMBX02 in the Primary Site are mirrored in terms of mailbox database copies.  PrimarySiteMBX03 and PrimarySiteMBX04 in the Primary Site are mirrored in terms of database copies.  PrimarySiteMBX01 and PrimarySiteMBX02 are mirrored with SecondarySitMBX0102 in the DR Site and PrimarySiteMBX03 and PrimarySiteMBX04 are mirrored with SecondarySiteMBX0304 in the DR Site.

To make it a bit more clear, the following image shows database distribution.  You can see there are 6 nodes and 3 copies of each database.

Should PrimarySiteMBX01 and PrimarySiteMBX02 go down (as illustrated below), SecondarySiteMBX0102 can automatically mount the database because majority is still there for quorum.  In this case, the RPC Client Access Array in the Primary Site will still successfully be able to provide mailbox access to the databases mounted on SecondarySiteMBX0102 in the DR Site.  This is one of the nice things I like about Exchange 2010 High Availability, is that if your DAGs go down, you can allow the copy in the DR Site to automatically activate (provided the Database Activation Policy as described above allows it to automatically mount) whereas in Exchange 2007, you had to manually activate any SCR copy.

Exchange 2007 and Exchange 2010 Clusters both use Majority Node Set Clustering.  This means that 50% of your votes (server votes and/or 1 file share witness) need to be up and running.  With DAGs, if you have an odd number of DAG nodes in the same DAG (Cluster), you have an odd number of votes so you don’t have a witness.  If you have an even number of DAGs nodes, you will have a file share witness in case half of your nodes go down, you have a witness who will act as that extra +1 number.

So in this scenario, we have 6 votes from the servers plus 1 witness from the file share witness totaling 7 votes.  This means we can have up to 3 servers fail and our cluster will still be online.  This is because if you are in the scenario where we 7 votes, if 3 go down that leaves us with 4 votes which satisfies the 50% + 1 majority rule. Because of this, we still have majority and our quorum and cluster are still fully operational.

Now when exactly would we have to do a manual switchover?  Well, there’s a couple cases.  The first would be if your Primary Datacenter has a complete outage.  This may be due to power failure, environmental disaster, etc…  The other is because all Primary Datacenter DAG members go down or just enough servers go down (again, 50% + 1 voters must be up which means if we lose more than 3 machines (includes FSW), our entire cluster goes offline.  In this case, you’ll have to do a manual datacenter switchover.  You’ll move over all services to the secondary datacenter including changing the RPC Client Access Server FQDN to point to the single CAS Server or the standby VIP that publishes RPC across multiple Secondary Datacenter CAS Servers.

Elan Shudnow :: Mar.04.2010 :: Exchange, Exchange 2010 :: 166326 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F03%2F04%2Fexchange-2010-rpc-client-access-service-and-multiple-sites%2FExchange+2010+RPC+Client+Access+Service+and+Multiple+Sites2010-03-05+04%3A52%3A12Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1663

Yes, this is old news and there’s about 462 blog entries (ok, that’s a made up number, but there are a lot) about how to force Communicator 2007 R2 to do an Address Book (Galcontacts.db) update.  These blog entries will talk about the July 2009 update for Communicator 2007 R2 and how it introduced a random delay of 0-60 minutes for Communicator 2007 R2 to download an updated GalContacts.db to prevent the network from getting hammered by so many clients downloading an updated GalContacts.db all at the same time.  And yes, these blog entries also talk about a registry entry you can create called GalDownloadInitialDelay and creating a Dword set to 0 in order to force Communicator to do an instant update.

Some blog articles that talk about this include:

http://www.tincupsandstring.com/2009/12/01/forcing-address-book-download/

http://www.markc.me.uk/MarkC/Blog/Entries/2009/12/17_Force_Downloading_the_Address_Book_in_OCS.html

Now I’m sure you are asking yourself why I am creating this entry?  Is it just to repeat information that’s already out there?  Of course not!

So, Communicator 2007 R2 is a 32-bit (x86) application.  That registry entry works perfectly fine on x86 systems.  But, if you are running on a x64 system, it won’t.  Why?  Well, because when you run x86 applications on a x64 based system, it utilizes a system in Windows called Windows on Windows (WOW64).  WOW64 has its own section within the registry called Wow6432Node.

So let’s say we take the registry key for our Communicator x86 (Communicator x64 not available) and run it on an x86 system.  The following registry key works fine:

But let’s say we have an x64 system.  The above registry key will not work.  We need to utilize the WOW6432Node part of the registry.  The following registry key works for x64 systems:

Please make sure you back up your registry before making changes as making changes to the registry can be harmful to your system if not done properly.

Elan Shudnow :: Jan.20.2010 :: OCS :: 161614 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F01%2F20%2Fforcing-address-book-updates-in-communicator-2007-r2%2FForcing+Address+Book+Updates+in+Communicator+2007+R22010-01-21+02%3A22%3A18Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1616

Exchange 2010 introduces a new moderation feature.  This moderation feature can be used to perform moderation on both messages submitted to a Distribution Group and/or requests to join a group through the self-service options provided by the Exchange Control Panel (ECP).

The Issue

For both the Distribution Group Mail Flow Message Moderation as well as the Membership Approval Moderation were both grayed out for us.  I did a dump of these two groups by running the following two commands:

Distribution Group Mail Flow Message Moderation

Membership Approval Moderation

The Fix

After taking a look at both .txt files, I noticed that the user that was specified under ManagedBy no longer exists.  I changed the ManagedBy to an existing user and all the Moderation feature options lit up and were no longer grayed out.

Keep in mind, you absolutely will need to have a Manager specified in order for the moderation features to light up.  This makes sense with the Membership Approval tab as it only allows you to use Group Managers.  For the Message Moderation, it would seem that Microsoft should not gray everything out by default when you don’t have a Group Manager specified since it does allow you to specify specific people for moderation instead of using the Group Manager.

You can use the following command to modify all your groups in bulk:

Update (1/20/2010) - I ran into another issue today where the moderation options were grayed out even with a valid group manager.  I changed the manager and changed it back and the moderation features were lit up.

Update (2/17/2010) – I forgot to update this with another issue after my 1/20/2010 update.  After updating the Group Manager for a group, the Address Book service in OCS seems to consider this group as an entirely new group.  This means that if people had this group added in OCS and you modified the Group Manager, that group becomes void in Communicator and stops expanding.  I had to end up deleting the GalContacts.db and let a client download a new GalContacts.db.  The client had to delete the group from Communicator and then delete it in order for the group to start working again.

Elan Shudnow :: Jan.19.2010 :: Exchange, Exchange 2010 :: 16061 Comment »http%3A%2F%2Fwww.shudnow.net%2F2010%2F01%2F19%2Fexchange-2010-moderation-features-grayed-out%2FExchange+2010+Moderation+Features+Grayed+Out%3F2010-01-19+19%3A11%3A10Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1606

OCS 2007 R2 Standard Edition Front Ends utilize SQL 2005 Express with SP2 for storing its databases.  Unfortunately, with SQL Express, you will have to backup using SQL Server Management Studio or find an automated way.  This article will detail the steps I utilize to make backing up easier and automated. For information on how to back up OCS, please see the Backup and Restoration Guide here.

The following data will ultimately need to be backed up:

1. Global Config
2. Pool Config
3. Machine Config
4. SQL Databases
5. Standard Edition File Shares

The first command specifies the /level to be global and pool.  The second command specifies the /level to be machine.  What we will do is create a batch file (.bat) and place both commands in this .bat and have them run against the server every 6pm using scheduled tasks.

Our Servername is SHUD-OCSFE01.  The folder to store the backups is C:\OCSBackup.  We’ll also be running the batch file from the C:\OCSBackup.  Because the folder which contains lcscmde.exe is not a part of the system variables, we’ll have to specify the entire path for lcscmd.exe. Taking this information into consideration, our two commands for our batch file will be:

After executing this .bat file, we can see the two files have been created.

SQL Databases

The following is the list of SQL Databases that an OCS Standard Edition Front End uses:

Because we are utilizing SQL Express, we will have to find some other method other than a backup agent to automate the backups. Much of the SQL Backup information is provided by the SQLDBATips Blog.  The following article I utilized is located here.

Create a file with the extension of sql in our OCSBackup folder.  Also, create a new folder called C:\Reports for script reporting. I created a file C:\OCSBackup\ocssqlbackup.sql with the following text:

exec expressmaint
@database      = ‘ALL_USER’,
@optype        = ‘DB’,
@backupfldr    = ‘c:\ocsbackup’,
@reportfldr    = ‘c:\reports’,
@verify        = 1,
@dbretainunit  = ‘days’,
@dbretainval   = 1,
@rptretainunit = ‘weeks’,
@rptretainval  = 1,
@report        = 1

exec expressmaint
@database      = ‘ALL_USER’,
@optype        = ‘LOG’,
@backupfldr    = ‘c:\ocsbackup’,
@reportfldr    = ‘c:\reports’,
@verify        = 0,
@dbretainunit  = ‘days’,
@dbretainval   = 1,
@rptretainunit = ‘days’,
@rptretainval  = 1,
@report        = 1

All of our OCS Databases are User Databases, not System Databases.  We can see this using SQL Server Management Studio which is not installed by default but can be downloaded from here.

Note: Keep in mind that we’re not using the default SQL Express instance of SQLExpress.  The OCS Front End Standard install will create and utilize an instance of RTC.

We now have our .SQL file created.  We’ll go ahead and create a new .bat file called ocssqlbackup.bat.  This batch file will run the following command:

This won’t work just yet.  You can see in the .SQL file, it’s calling the stored procedure “expressmaint.”  We need to create this stored procedure within SQL.  SQLDBATips has the vbscript code in order to do that here.  You take this code and save it as storemaint.sql.  Then run the following code:

Note: The website that shows these instructions specify the -S.\ as -S.\SQLExpress.  Again, we’re not using the SQLExpress instance, but rather the RTC instance.

You can delete the expressmain.sql file now.  This is a permanent change in our instance and we won’t need to run the expressmain.sql script again.

We should now be able to run our SQL backup batch file as our .sql command that specifies our databases and logs has been created and our batch file to call sqlcmd.exe to execute our .sql file has been created.

We can see our ocssqlbackup.bat file successfully runs and creates backups of our databases.

Scheduled Tasks

We obviously want to keep backing up our databases every night in case something goes wrong.  We’ll create two scheduled tasks.  One that runs ocsbackup.bat for our global, pool, and machine specific information.  And the other that runs our SQL Backups.

I am launching the Task Scheduler from Server Manager (I am using Server 2008 but you can access Task Scheduler on Windows 2003 by going to Control Panel).

Create a Basic Task and give it a name.  We’ll name this OCS Backup.  Click Next to Continue.

Specify how often you want the task to run.  I typically run it Daily. Utilize whatever method works best for your organization. Click Next to Continue.

Choose what time the Daily Task will run.  Again, choose whatever time works best for your organization. Click Next to Continue.

We’ll want to run the script.  Because of this, choose “Start a program.” Click Next to Continue.

Specify the path to our batch file. Click Next to Continue. Review the Settings and then Click Finish.

You can then forcefully run the Scheduled Task to ensure it runs.

Now don’t forget to create the second scheduled task to run the batch file for SQL Backups!

Your OCSBackup folder should look something like this after your scheduled tasks run and your data is backed up.

Backing up your data to a remote Backup Server

Now what good is having all this data backed up onto the OCS File System if OCS crashes?  No good!  We’ll still want to take your backup system and back up all these files including the OCS Standard Edition File Shares.  Now keep in mind that you will want to back up all of these files at some time after your batch files are set to run in Scheduled Tasks.  For example, my Scheduled Tasks are set to run at 8pm.  The batch files do not take long to run.  You can have your backup set to run at 8:30pm or 9:00pm.  Be sure to test and validate this is working as intended and you are getting successful backups.

The Standard Edition File Shares you will want to backup include:

So to sum it up, you will want back up all the above file locations and your OCSBackup folder.  Backing up your Reports folder is optional. But again, keep in mind you will want to run this file level backup after all your Scheduled Tasks are successfully run.

Elan Shudnow :: Jan.18.2010 :: OCS :: 15866 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F01%2F18%2Focs-2007-r2-standard-edition-front-end-automated-backups%2FOCS+2007+R2+Standard+Edition+Front+End+Automated+Backups2010-01-18+16%3A22%3A04Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1586

After recently doing an Exchange 2007 SP2 Upgrade and Rollup 1 for SP2, I encountered an issue with Impersonation.  I’m assuming this happened due to the SP2 Upgrade, not the Rollup, but be cognizant about the issue either way.  For this upgrade, Geomant Message Waiting Indicator (MWI) for Exchange 2007 Unified Messaging was being utilized.  Geomant MWI utilized Impersonation in order to light up the telephone when the user receives a voicemail.  This stopped working after the SP2/RU1 was applied to the system.

The issue

The error message we saw was as follows

2009-12-17 22:56:37,744 ERROR Com.Geomant.Exchange12.MWIService.ExchConnector – Failed to create search folder by using WebService for user: CN=Lastname\, Firstname,OU=OUHERE,DC=domain,DC=tld. Reason: The server to which the application is connected cannot impersonate the requested user due to insufficient permission. [1488]

2009-12-17 22:56:37,760 ERROR Com.Geomant.Exchange12.MWIService.ExchConnector – Failed to subscribe the user: CN=Lastname\, Firstname,OU=OUHERE,DC=domain,DC=tld for Exchange events.  [1488]

The fix

Run the commands to grant the service account impersonation rights as it previously had.  Please refer to the documentation previously used for granting impersonation. In the case of MWI, the following two commands were run:

Elan Shudnow :: Dec.18.2009 :: Exchange :: 1566No Comments »http%3A%2F%2Fwww.shudnow.net%2F2009%2F12%2F18%2Fupgrading-to-exchange-2007-sp2-and-impersonation%2FUpgrading+to+Exchange+2007+SP2+and+Impersonation2009-12-18+21%3A01%3A13Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1566