RSS Subscription 168 Posts and 2,769 Comments

Archive for January, 2010

Forcing Address Book Updates in Communicator 2007 R2

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:

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:

Windows Registry Editor Version 5.00


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:

Windows Registry Editor Version 5.00


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.


Exchange 2010 Moderation Features Grayed Out?

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:

Get-DistributionGroup “Group 1” | FL |  Out-File C:\Groups\Group1.txt

Get-DistributionGroup “Group 2” | FL | Out-File C:\Groups\Group2.txt

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:

Get-DistributionGroup | Set-DistributionGroup -ManagedBy “Manager Here”

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.


OCS 2007 R2 Standard Edition Front End Automated Backups

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.

lcscmd /config /action:export /level:global,pool /configfile:<drive>:\<path>\<filename>.xml /poolname:[name of Standard Edition server, which is used for the pool name]

lcscmd /config /action:export /level:machine /configfile: <drive>:\<path>\<filename>.xml /fqdn:[FQDN of server from which settings are to be exported]

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:

“C:\Program Files\Common Files\Microsoft Office Communications Server 2007 R2\LCSCmd.exe” /config /action:export /level:global,pool /configfile:C:\OCSBackup\SHUD-OCSFE01_GlobalPool_Backup.xml /poolname:SHUD-OCSFE01

“C:\Program Files\Common Files\Microsoft Office Communications Server 2007 R2\LCSCmd.exe” /config /action:export /level:machine /configfile:C:\OCSBackup\SHUD-OCSFE01_Machine_Backup.xml /

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:

“C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe” -S.\RTC -i “c:\OCSBackup\ocssqlbackup.sql”

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:

“C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe” -S .\RTC -i c:\ocsbackup\expressmaint.sql

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.