All posts by Mubashir

WorkSite Tips & Tricks

Upgrading to WorkSite Communications Server 8.5SP2

2 Comments

I first saw a demo of WorkSite Communication Server 8.5SP2 when it was introduced a year or so ago. Since then its had some missed deadlines but finally was released in GA a couple of weeks ago. Partly the reason for its delay however was because of the many architectural changes in the software. The underlying code has been completely overhauled and the operation of WCS 8.5SP2 has been changed in a number of ways.

WCS 8.5SP2 has a number of key features all rolled up into one release

  • Greater integration with Exchange 2010 CAS
  • Load Balancing across multiple WorkSite Communication Servers
  • Mailbox Sync/Mailbox Agent
  • Numerous bug fixes

 

If you are moving to Exchange 2010 and currently have WCS SP1 installed you may want to check my earlier post for further information.

In this post I’ll focus on a couple of the features that come with SP2 and share with you some of the useful tips I picked up along the way.

Exchange 2010
One of the eagerly anticipated feature of this release, especially for larger firms, is the deeper integration with Exchange 2010. In SP1 EFS configuration was based around filtering on the WorkSite database/Exchange server pair; which was fine until the number of filing folders in a single database increases to unmanageable levels (how much time have we all spent waiting for that EFS pane to refresh praying it won’t crash??). Even then you could have explicitly list your Exchange 2003 mailbox stores (until of course the number of folders per database per mailstore got too large!) to filter further.

In Exchange 2010 Microsoft recommend you use the CAS alias for all external apps, meaning you were confined to using just one server if you couldn’t split your WorkSite database config down further. Autonomy still allow you to filter Exchange 2010 mailbox/database, however with the introduction of Load Balancing, this is less of a necessity.

Load Balancing using iManage Clustering
The core problem with running multiple WCS SP1 servers was that they all ran independently and it was up to the WorkSite Administrator to set up each of their functions according to infrastructure resources and business requirements. If one of the servers failed there was no mechanism for the processing to fail over to another server. In SP2, Autonomy require an installation of iManage Clustering, the same service that clusters middle-tier servers together. This works pretty well, you can now have multiple servers processing the same setup together by the efficient Clustering service.

I would advise you spend time to get to know how Load Balancing works. The recommended setting is to enable Automatic Load Balancing and let the system run on auto-pilot. This works well, on the whole, the users are split evenly across each server with the ValidUsers.urs file dynamically updated whenever there is a change in one of the nodes across the WCS cluster. Bear in mind once you click on Connect, all the options are greyed out and you will no longer be able to make any config changes. Just as well really, I agree with Autonomy this is necessary to prevent any unintended user action that may disrupt the process.

You may choose to run the manual Load Balancing, which is mandatory when filtering users according to WorkSite group. This is definitely a gem in the release; as a WorkSite Administrator I’ve come across a situation many times where users complain folders have not been processed for filing or some other problem. In SP1, to troubleshoot the problem meant to let MarkingWork complete a run and then trawl through the logs. However the logs can get chatty (in SP2 unfortunately the situation has gotten worse) and it is difficult to filter threads for a particular user. In SP2 all you have to do is add the user(s) into any WorkSite group, add the name of your group under User Group Name and away you go, MarkingWorker now only targets the users you want. Simple, but brilliant.

SP2 Tips

  • Use the new functions available to SP2 to go through your infrastructure again and see if it needs to be tuned. Especially if your firm is over the intial period of introducing 8.5 client, you may want to re-evaluate whether you still need to have an aggressive polling interval.
  • It also might be an opportunity to do some housekeeping & go through the EFS console to remove some of the folders marked Failed as a result of the user filing and then deleting them from Outlook. If in doubt, reset the folder and attempt to process again so you can be sure its ready to be deleted. Alternatively, you may want to check the status of the folder from Outlook.
  • Consider using User Group Name, should you want align your EFS configuration to target particular users more than others.
  • Be aware of how big the logs can get. Currently there is no way to tone down the logs from Verbose. The available setting only allows to tone down to Information or Error in the EFS console view.
  • Although you may not be using Mailbox Sync and have it set to Manual or Disabled; you still need to review the settings you have set in this node in EFS. In particular, notice how any WorkSite/Exchange settings change you make also get replicated into this window (under the Exchange Servers/WorkSite DMS area). If it hasn’t replicated, click away and then back again.
  • Clustering the EFS servers will require a DNS alias first, so get these in place before you begin your upgrade. If you aren’t using clustering, you are still required to input the hostname in the Cluster Name field.
  • When using Load Balancing, note how EFS generates files in the (hidden) ProgramDataAutonomy folder until LoadBalancer has finished at which point the ValidUsers file is placed in the Config folder. This file is the heart of the Load Balancing operation and initiates & controls the process.
  • Using Automatic Load Balancing means each node in the cluster has a number of users held in the ValidUsers file for that node to process. This will not get refreshed until there is a connect/disconnect on that or other nodes within the cluster. Which is fine, until the time you have new users added into your WorkSite databases who will soon start to create Filing Folders. These new users will not get added until there is a refresh and the ValidUsers file is reloaded.

 

What do you think of WCS SP2 so far?

 

Mubashir Mian is the Lead System Specialist at a major international law firm. His LinkedIn profile can be viewed here (http://uk.linkedin.com/in/mubashirmian)

Share
General Legal IT, WorkSite Tips & Tricks

Migrating to Exchange 2010 with iManage WorkSite Communication Server

3 Comments

Quite a few Autonomy customers have implemented 8.5SP1x WorkSite Communication Server (WCS) to take advantage of the enhanced server-side filing features brought in by the new Email Management (EMM) client. Although the legacy “send & file” functionality existed before 8.5, it was a bit clunky & basic. Using the filing toolbar and other neat features bought the fee-earner even closer to matter collaboration and email volumes in WorkSite have increased.

Separately, there has been a push in the enterprise towards Exchange 2010, as the Exchange Administrators are keen to make use of the CAS high availability and new Outlook Webapp amongst other features, the most obvious one being Outlook 2010

This blog post will take you through some of the things to note when migrating your mailboxes from Exchange 2003 to Exchange 2010 and what the impact might be on your WorkSite user.

First the easy bit, the legacy WCS (SMTP) service that runs the filing via email address. There are no major changes to carry out here. The email filing functionality at the back end is still the same, with the SMTP service on the WCS picking up the incoming mail directed to it from your Exchange server using the mail connector The mail connectors from your Ex2003 environment will have automatically been migrated to your Ex2010 so things should pretty much remain the same, so any mail destined for yourworksitedomain.yourdomain.com will still go through. If you want to reconfigure the bounced email to be redirected to your new service account, (see below for why you need a new service account) you can make this change quite simply in the Communication Server Properties. A restart of the WCS service will be necessary, however the messages will queue during this time.

Things get a bit more interesting when it comes to the Email Filing Service (EFS). The EFS handles two of the main services, the FilingWorker (for Email Filing) & MarkingWorker (for Filing Folders). There are two key changes to be made within the EFS when the mailbox migration process begins.

First of all you need to review the Email Server Connection tab. Here you will have added the details of a Ex2003 service account which has relevant Send As/Receive As permissions. This service account field needs to be updated to a Ex2010 service account (a mailbox hosted within Ex2010). I guess you could also migrate the existing service account but I wouldn’t advise this, just so it doesn’t impact your current environment. Naturally, the Send As/Recieve As permissions need to be added for this account and should also have this access to the Ex2003 environment. In the Service Account/Server Name field you need to put in the name of your Ex2010 CAS name, whether this be a single server or an alias for the array and ensure you add this using the FQDN. All this can either be done manually or via the Email Filing Server Configuration Wizard, which will also change the local Outlook profile on the server to the new service account. If you use Trusted Login with the WorkSite administration account on EFS then you should ensure this has relevant NRTADMIN permissions in the database.

Secondly, depending on how many WCS’s you have and how they are individually configured, you may be filtering the Email Server Connection according to how you want each WCS to service Exchange. If this field was left blank, so the EFS could connect to any mailbox, then you can leave it like this. If however, you are using more than one WCS OR explicitly defining the Ex2003 mailbox stores, then you will need to add the same Ex2010 CAS name that you added into the Server Connection/Mailbox servers field. The benefit of explicitly defining what Exchange servers I want to filter on is it helps with troubleshooting and also keeps the WCS for the two Exchange environments separate. On the other hand you may wish to remain Ex2003/10 agnostic and want to leave it blank.

After you have saved the above settings you should run Test User Connections against both Ex2003 & Ex2010 users to ensure everything has gone through smoothly. Clicking on Marked Folder Management you should still see the listed of Filing Folders you had as before.

A subtle change to review is that any MarkingWorker or FilingWorker jobs carried over prior to migration will appear exactly the same in Folder Sync Monitor/Email Job Monitor lists. However, any new Filing Folders created or any new Filing jobs queued will have their mailbox entry prefixed by the Exch2010 CAS name.

So to summarise

  • Have a new Ex2010 service account with relevant permissions
  • Update the Email Server connection to use this account with the CAS name
  • Consider how best you can use the Exchange filter, to help you with troubleshooting and splitting across multiple WCSs
  • Set up a few test accounts with Filing folders, migrate, set up a few more and see how these differ in Folder Synch Monitor area. The same principle will apply in the Email Job monitor pane.
Share