Category: Application

A short review of PeerLock and how it has worked (and hasn’t) for us.

One of the disadvantages of DFS is the lack of File Locking. If you have a file open on any member server, and someone opens the same file on a different member server, you will receive no notification that the file is in use.

This is explained in more detail here: http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx

This review is mostly a grouping of my comments on that blog post.

What is it?

PeerLock (http://www.peersoftware.com/products/peerlock/peerlock.aspx) is software used to facilitate locking of files between servers.

It is installed (and licensed for) each member server that contains a copy of the files you want to lock. In our case, we have one hub DFSR member, and 3 spoke DFSR members. We set up the PeerLock program to watch each of our DFSR shares, with the target being the same DFSR share on the spoke servers.

How is it?

Well, for us, it didn’t work out. We are still using PeerLock, but in a much reduced role.

Note: this is based on version 2.02. We haven’t budgeted for an upgrade to the latest version, so performance may be improved.

Since we are replicating about 900 GB of data, with 100`s of files open at once, across business ADSL connections, PeerLock ended up causing many replication issues, conflicts and sharing violations.

At times, by 8:30AM we would have over 1000 files in the backlog, and they wouldn`t clear because DFSR had too many sharing violations. Through experimentation we found this was directly caused by PeerLock.

Because of this we have begun using it only for high-collaboration folders, instead of our entire DFSR shares.

On a smaller scale, it has been working great, and other than the steep price I would recommend it. Our files and folders that are commonly shared between offices are protected, while the majority of our files which are used by only one office are just monitored for conflicts.

Here are some considerations when using PeerLock:

• Peerlock can run as a GUI, or a service, but not both. This means to run on a server that is logged off, you need to use the service, but to make configuration changes, you have to stop the service, start the GUI, make changes, close the GUI, start the service.
• CPU usage is very high with a large amount of files protected. The program was using about 35% CPU constantly, on a 2009 PowerEdge 2900 server with a single Quad Core CPU.
• Price – it was somewhere around $990 CAD per license, and you need one for each server.

If you are using PeerLock, here`s a knowledgebase article that really helped reduce some of the issues:

http://www.peersoftware.com/support/kb/kbarticleprintpreview.aspx?id=KBA-01128

Another post that is slightly related to our Symantec Endpoint Protection (SEP) testing; on our Windows 7 machines, we’ve found that with SEP installed and enabled, the jumplists for all programs are drastically slower to appear.

As soon as the antivirus auto-protect is disabled, performance returns to immediate. This slowdown was most notable on Windows Explorer jumplists, however it also affected Microsoft Office and other programs.

I eventually found a solution, related to an obscure location for the jump list cache.

Sign in as the user having the problem, and paste this into an address bar:

%AppData%\Microsoft\Windows\Recent\AutomaticDestinations

This folder contains a cache of the Jumplist entries. To fix the issue for Windows Explorer, find the entry that begins with:

1b4dd67f29cb1962

And delete it.

Then navigate here:

%AppData%\Microsoft\Windows\Recent\CustomDestinations

And do the same thing; delete the file that starts with:

1b4dd67f29cb1962

After this you will need to re-pin any items you previously had pinned for that application.

This will only resolve the problem for Windows Explorer; you may have to do some trial and error to find the appropriate cache to delete for any other programs.