This guide will cover the various aspects of replication for a Prolaw SQL server.  If you have a replicated environment and are updating any aspects of Prolaw such as the custom tabs or updating Prolaw itself, you will need to stop replication first.  You may also refer to this guide if you need to set up a replicated environment.  This guide will focus on the SQL portion itself, assuming you already have the document shares replicated via DFS or other means. You may refer to other posts on this blog on how to set up test versions of Prolaw or how to install updates.

If you are working with any Prolaw updates, adjusting a replicated environment, or conducting any other related work it is always best practice to ensure all users are out of Prolaw so that there is no potential for lost work product.

Break existing replication:

If you have an existing replication, and are not making any changes to SQL, its enough to simply delete the subscriber and leave the Publisher configured as is.

Step 1:  Verify all Prolaw Agents or Exchange Integrations are stopped and all users are logged out of Prolaw.

Step 2: Verify databases are currently synchronized, and then stop them through the replication monitor in SQL.

Step 3:  Delete the subscription on the secondary server (the Subscriber).

If you are updating Prolaw:

If you are updating Prolaw in a replicated environment, there are a few more steps involved.  Its also going to vary for every firm depending upon related server and network settings.

Step 1:  Update the primary Prolaw server following the standard Prolaw update process (http://www.advancedlegal.com/blog/installing-a-prolaw-version-update/).

Step 2: Archive the updated Prolaw install directory and the updated SQL database and copy to the Subscriber server.

Step 3: Restore over the current Subscriber’s Prolaw database with the updated database from the Publisher (see note).

Step 4: Overwrite the Prolaw application directory with the archive from the updated server, being sure to not overwrite prolaw.ini as this file contains the specific server settings for Prolaw

Note:  If you are not using DFS for documents, prolaw.dbo.prolawini will most likely be excluded from the replication/overwriting as that would contain the path to the document share and would be different in all locations.

If you are creating a fresh replication:

If you want to setup a new replicated Prolaw site, you can start here.  This assumes you have Prolaw installed and tested at the remote site.

Step 1:  Create a publication on the primary SQL server by right-clicking publications and selecting “New Publication.”

Step 2: For the new publication options, use the default options unless shown below:

- Set the server as the Distributor.

- change the default replication folder if needed; otherwise the default is okay.

- select the database you use for Prolaw.

- select “Merge Publication.”

- use functionality level of the lowest member (preferring that they are all the same version).

- select all tables excluding as needed (see note).

- provide a user account for the Spanshot Agent and Publisher.

Note:  If you are not using DFS for documents, prolaw.dbo.prolawini will most likely be excluded from the replication as that would contain the path to the document share and would be different in both locations.

Create the new subscription:

Once Prolaw has been updated or you have created a new Publication, in order to restore the synchronization, the final step is to (re)create the Subscriber.

Step 1: Create the new subscription on the Publisher ensuring the Prolaw database is available.

- select run all agents at the Distributor.

- add the SQL server subscriber and select the correct remote database.

- use a domain administrator account for the Merge Agent.

- select continuously or a schedule for the synchronization to happen.

- Initialize immediately, using the defaults for the rest and creating the subscription.  The initial verification could take hours depending on your connection to the other SQL server.

Step 2: Verify and test the synchronization in the SQL monitor.

TEST!!!

Any time you make any changes of this magnitude to SQL, Prolaw, or a replicated system, the most important step is to ensure your programs are acting as they should and data is being replicated correctly before users start to work.

If you file a zipped archive, the name of the zip file as well as the zipped file’s contents are indexed.  However, if you search for the file name of a file that is in that zip, it will not return any results.  This is by default, and needs a slight adjustment on the IDOL index server.

Example:

Zip File Name:  testzip.zip

Zipped File Name:  avacado.txt

Text File Contents: Guacamole

If conducting a full text search of “testzip” or “guacamole” you will return this file, however “avacado” will bring up no results.

To resolve:

Open the content engine CFG file.

Locate the “ProperlyFieldCSVs=” line, and add “*/DREORIGINALNAME”

The whole line will now read: “PropertyFieldCSVs=*/DRECONTENT,*/BODY,*/DREORIGINALNAME”

Repeat for all Content and Active Content Engines.

Restart IDOL services and confirm with a test file.

Recently, I ran into an issue where a piece of software that integrates with exchange had “merged” some of the user’s contacts resulting in many contacts going missing from the accounts.  There are various ways to resolve this from backups, and I’ll mention three in this post.  Due to the issues with this particular setup, I will only go into details for the third option which is what was done.

This assumes you are familiar with Active Directory, Exchange System Manager, the Exchange Console, and have full access to user’s mailboxes.

Option 1: Granular Restore with Symantec Backup Exec

As this setup is using Symantec Backup Exec, the GRT was not working due to a version inconsistency, or this would be the normal default for any restoration of Exchange information.

Option 2: Exchange Recovery Storage Group (RSG)

After working with Microsoft support for this issue to ensure no data was lost and there was minimal downtime for the users, we were unable to use this feature.  The reason is, the only reliable backup of the contacts was from some time back.  Using RSGs, you are only able to merge the two versions of the mailbox in its entirety.  If we did this, the contacts would return, but so would many other deleted emails or calendar appointments.  This would also cause issues with the calendaring agent from ProLaw seeing various copies of older items.  According to support, you are unable to select a specific folder to merge, only the entire mailbox for that users account.

An option was to restore the user’s data to a new temporary account, then archive the contacts out.  Once that is complete, we would have to delete the folder, and export the data for the next account.  Ultimately, this would take many hours while copying the entire mailbox to the temp account.  Here is the Exchange code to merge the data to a new user’s mailbox:

restore-mailbox -Identity “TEMP ACCOUNT” -rsgdatabase “[path to RSG db]” -rsgmailbox “SOURCE MAILBOX IN RSG” -TargetFolder “Folder to restore data to]

Option 3: Mount/Extract data from a Separate Store

Ultimately this is the option we went for.  We restored the database DB file to separate location, and mounted it with a different name inside a separate store. We then connected the mailboxes to a temp account to extract the contacts to a PST file for each user.  This allowed the users to experience no downtime or interruption.

Step 1 – Notify users of downtime, as you will need to disconnect their mailboxes.

Step 2 – Restore the mail DB to separate file, mount this to a new storage group in Exchange naming it as you see fit.

Step 3 – Once mounted, in the Exchange System Manager, you can check the “disconnected mailboxes” to ensure that all the users mailboxes are present and disconnected.

Step 4 – Locate the live user’s account in the Exchange System Manager, right-click and select “Disable”  DO NOT SELECT REMOVE! If you select remove, you delete the user’s AD account as well!

Step 5 – Navigate to the disconnected mailbox of the user you have just disabled in your temporary Storage Group (careful here, you will see two for that user, make sure you select the one in the correct temporary Storage Group you created earlier), right-click and “Connect” the mailbox to an AD with which you have access and can open the mailbox.

Step 6 – Open Outlook as the account you just connected the mailbox to, and archive out the needed data to a PST file.

Step 7 – Returning to Exchange System Manager, “Disable” the mailbox you have just linked in the previous step in the live storage group.

Step 8 – In the disconnected mailboxes, connect the user’s live mailbox back to their AD account.

Step 9 – Log in as that user, verify mail is flowing, and import the PST data you have just created.

If you are migrating to, or have imported emails into FileSite, you may not have the header information imported from the email.  This can include the To, From, Sent Time, and Received Time.  Luckily, Autonomy has a utility to open the emails and import the header information, but it requires a decent amount of setup and testing prior to running.  You will need full access to SQL and the WorkSite server for this task.  You will also have to download and install the Resource Kit from Autonomy (available from their support site with login).

Determining Documents to be Fixed:

The first step is to isolate the range of emails that need to be fixed. To do this, we will query against the FileSite database to find which documents have NULL fields.

select docnum, docname, t_alias, c13alias, entrywhen from mhgroup.docmaster
where c13alias IS NULL and t_alias = ‘mime’ order by entrywhen

This will result in all emails that have c13alias (From) as NULL, and order them by date.  Make a note of first and last emails “Entry When” date, as well as one document number we can use to test

Installing the Resource Kit:

Once you download and install, there are many components as part of the kit, but we need to make sure at least the MSGFIX utility gets installed.

Registry Keys: The application will reference registry keys that you must manually create to map the header fields to their respective custom fields in FileSite.  The following are the default values, but if you have customized your system please verify and update as needed:

Reg keys for 64bit:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Interwoven\Worksite\Server Common\Custom Fields Map]
“From”=dword:0000000d
“To”=dword:0000000e
“Sent”=dword:00000000
“Receive Time”=dword:00000016
“Send Time”=dword:00000015
“CC”=dword:00000000
“BCC”=dword:00000000

Reg keys for 32bit:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Interwoven\Worksite\Server Common\Custom Fields Map]
“From”=dword:0000000d
“To”=dword:0000000e
“Sent”=dword:00000000
“Receive Time”=dword:00000016
“Send Time”=dword:00000015
“CC”=dword:00000000
“BCC”=dword:00000000

XML configuration: There will be a CONFIG.XML file in the installation location that needs to be edited.  32 Bit: C:\Program Files\Interwoven\WorkSite\Server, or 64 bit: C:\Program Files (x86)\Interwoven\WorkSite\Server.  Open this in your XML editor or simply notepad.  We have two sections to edit, the first is the DB connection and the second is the filter for which emails will be affected.

DB Connection: find the <DBConnection dsn=”database name” user=”user” pwd=”password” /> and replace the quoted information with your server information

Filter:  There are MANY different ways to filter the information.  This will cover two methods, the first will run against a specific document number for testing purposes, and the second will run against a date range (full update).   The red text represents what should be edited.

Specific Document Number:

<DocFilters>
<Filter column=”DOCMASTER.DOCNUM” value=”123456” opp=”E” type=”numeric” />
</DocFilters>

Date Range:

<DocFilters>
<Filter column=”DOCMASTER.ENTRYWHEN” value=”CONVERT(datetime, ‘4/1/2003 0:00:00‘)” opp=”GE” type=”date” />
<Filter column=”DOCMASTER.ENTRYWHEN” value=”CONVERT(datetime, ‘1/26/2011 0:00:00‘)” opp=”LE” type=”date” />
</DocFilters>

Running the MSGFIX utility:

Once the application is installed, the registry keys are created, and the XML file has been updated, we are ready to run the utility.  When running agianst the full data set, the WorkSite Server should be stopped.  When this is running against one document, it should be okay to leave it running.

In the installation directory, create a batch file with the following contents. This is what you will use to actually run the utility:

32 bit:  “C:\Program Files\Interwoven\WorkSite\Server\MsgFix.exe” -mod e -cnfg “C:\Program Files\Interwoven\WorkSite\Server\config.xml”

64 bit: “C:\Program Files (x86)\Interwoven\WorkSite\Server\MsgFix.exe” -mod e -cnfg “C:\Program Files (x86)\Interwoven\WorkSite\Server\config.xml”

BACKUP YOUR WORKSITE DATABASE BEFORE YOU RUN ANYTHING!

Test on one document first:

First, we want to run the utility against a single email with missing information to confirm it will run correctly.  To do this, adjust the xml with the single identified document number from earlier.

Run the batch file.  Review the imMsgFix.log file in the same directory for errors.  This looks good for one document:

Mon 11/07 13:35:47.229       : 573:Info2 [10292] START: MsgFix in execution mode.
Mon 11/07 13:35:47.402          :1209:Info2 [10292] updateProfile is successful for docnum :220881 and version: 1
Mon 11/07 13:35:47.435          :1229:Info2 [10292] FINISH: 1 MIME-type Documents fixed
Mon 11/07 13:35:47.435          :1238:Info2 [10292] No Errors found.
Mon 11/07 13:35:47.436       :  79:Info2 [10292] MSG Fix Successful
Mon 11/07 13:35:47.436       :  88:Info2 [10292] **** Ended MsgFix ***********

Run against entire data set:

If after updating the single document, it looks correct in FileSite, you can assume the rest will be the same.  Adjust your dataset in the config.xml, stop the WorkSite server, and run the utility.  Monitor until the log shows its complete, restart the server, and verify in Outlook.

The ALA , Association of Legal Administrators, publishes a quartely issue of the Oregon Chapter’s Legal Management News. This fall the publication includes an article written by our very own Applications Consultant, Mike Smith.  “What is PDF/a and why does my firm need it?” is located on p. 20 of the fall issue. 

PDF, also know as “portable document format”, has been with us for some time, and thanks to Adobe, it will likely be with us long into the future.  The core idea behind the “portable” part of the title is that it should not matter what computer, operating system, phone, or tablet you choose to use, there is software that will allow you to open the document.  Read more http://www.oregonala.org/images/downloads/lmn/LMN%20Fall%202011.pdf

When your firm is updating to a new version of ProLaw, you want to thoroughly test it before you put it into production.  You want to make sure any customizations you have made are not broken, all of your settings have come over, and any other important firm functionality works as expected.

Note: This guide will assume you have knowledge of SQL and ProLaw.

Step 1: The first step is to take a backup of your ProLaw SQL database.  Save this to a separate directory.

Step 2: Restore the backup to a NEW database called “ProLawTest” and change the recovery model to “simple” as we do not need transaction logs.

Step 3: Create a new share on your ProLaw server called ProLaw Test.  Copy the contents of your current ProLaw share to the ProLaw Test share.

Important note: If you are using the DEFAULT document share (\\server\prolaw\documents) you may omit that directory if you do NOT want to test document filing and editing.

Step 4: Navigate to your ProLaw Test directory, and open “prolaw.ini” with notepad.  Edit the “dbname” line to reflect the name of your test database, in this example ProLawTest:

Step 5: Create a shortcut to the Prolaw.exe in the ProLaw Test share.  Make sure you name the shortcut ProLaw Test so you are aware it is a test.

Step 6: Open the test copy of ProLaw, using the userid switch if needed, as an account with full administration rights in ProLaw.  Go through the system preferences and disable any integrations with Exchange, Outlook, Word, or any other applications.  If you would like to test Exchange integration, you will need a separate exchange server for the test.

Step 7: Once any application integrations are disabled, we need to redirect the document share.  This setting will depend on your firm and how you want to test this version of ProLaw.

Case 1: If you have a copy of your document share as a test, you will need to direct it to the test document share.  You can edit, create, delete, and test with documents as needed.

Case 2: If you DO NOT have a test copy of your document share, you can leave this to live document share.  In this case, anything you edit, delete, or create will be in the live document share and affect current users.

Case 3: Set this to an empty directory to test document creation, and editing or deleting of only the documents you have created

Step 8: You are done.  You now have a stand-alone copy of ProLaw to test setting changes, customizations, or any other aspect of the program without affecting the current live users.

This guide will explain how to update ProLaw from one version to the next.   In this example we will be updating a test copy of ProLaw (see previous blog post).  The steps and results are exactly the same for the live version.

Please ensure everyone is logged out of ProLaw before you begin.

Step 1: Download the update from Thomson Elite.

Step 2: Create backups.  We want four separate backups by the time we are done.  The first two are as follows:

1 – ProLaw Test SQL pre-update

2 – Copy of the ProLaw Test share pre-update (zip file)

Step 3: The next step is to run the updater you downloaded previously.  You will need to run the program as a domain admin WITHOUT restricted access from the local machine it will be installed on.  You will also need to make sure you are running it as a ProLaw user account with full administrative access.

You will then need to navigate to the EXISTING ProLaw directory. This can be the test you have created or a live installation.

Enter the password that Thomson Elite has provided you for this update:

The installation should now be complete.  If you had any errors, you can view the “update.log” file in the directory you are upgrading ProLaw in.

Step 4: Launch ProLaw and ensure you are updated to the desired version.

Step 5: Create backups.  Since we want four separate backups by the time we are done, the last two are as follows:

3 – ProLaw Test SQL post-update

4 – Copy of the ProLaw Test share post -update (zip file)

Step 6: Archive your pre and post backups as needed.

Occasionally the views applied to various FileSite document folders become corrupt and display the incorrect information for that type of document.  An example would be email-style headers such as To, From, Sent, Received being the column headers for a folder that contains letters.  This will limit what you are able to see.

Step 1 :  Ensure you are in the FileSite Default View

Step 2 :  If the view is correct, but the columns are still incorrect, you need to reset the NRT*** views in Outlook.  To do this ensure outlook is closed, and delete the following files NRTEmailView.vdm, NRTView.vdm, and NRTWorklistView.vdm.  These files live in two locations:  “C:\Program Files\Interwoven\WorkSite\iOutlook” and “C:\Users\[user name]\AppData\Roaming\iOutlook”.

Note: these files must be deleted from both locations with Outlook closed.  This will also lose any broad customizations you have done to the view to apply to ALL folders with that view such as adding/deleting columns, changing size, or changing order of the columns.

Step 3 :  Check document folder to ensure view has returned.  If it hasn’t, ensure the folder is set to the correct view, normally “NRT Default”

—————

Expanding this beyond FileSite?

The VDM files are where Outlook stores its view settings.  If someone customizes one and other users want it, its possible to distribute these files.  Make sure you overwrite all of the proper VDM files, as they live in various places.  You can also make these read-only to prevent edits.

BIPro, financial management software makes it’s debut in ProLaw’s newsroom!

ProLaw and Advanced Legal Systems Extend Partnership

Integrating BIPro with ProLaw Back Office will Enable Clients
to Easily View Complex Financial Information, Saving Time and Increasing Efficiency
http://www.elite.com/prolaw-and-advanced-legal-systems-partnership/

Advanced Legal Systems, Inc. is now a  partner and value added reseller for InFocus a premier provider of projectors and the new Mondopad, a state of the art collaboration tool.

The Mondopad was displayed at the ILTA conference in Nashville this past week with rave reviews from office administrators, directors of Infrastructure Technology and managing partners of law firms nationwide!

The Mondopad turns conference rooms into collaboration rooms, with cloud based services that play nice with nearly all platforms.  Easy and familiar applications are optimized for touch including whiteboarding features for document sharing.  The video conferencing features are flexible and affordable.  This 55″ touch pad is impressive to say the least!  Maybe bigger is better?