PCmover Enterprise

 

PCmover Enterprise

PCmover Enterprise, on the other hand, provides organizations with a way to centrally control much of the PC migration process via policy. From a central console, administrators can define and enforce migration policies that pinpoint what can and cannot be transferred to new PCs, as well as customize the amount of interaction that end users can have prior to the migration. 

PCmover Enterprise comprises two elements: the PCmover Policy Manager and the PCmover Client. With the former, administrators define multiple policies that dictate (or exclude) the files, applications and settings targeted for migration; enumerate which PCs are targeted for both ends of the migration; and define which users can perform the migration. The PCmover Client, which can be stored on a network share or distributed via removable storage, is the engine that performs the actual migration. Analogous to PCmover Professional, PCmover Client culls the files, applications and settings from the old machine and then copies and installs that bolus of data to the new machine.

PCmover Policy Manager can be installed on a Windows server or workstation in the network; the PCmover client just needs to be kept in a share accessible to end users.

When installing PCmover Policy Manager, PCmover Enterprise automatically creates an editable Master Policy file that will be used for every migration action. Since this policy will apply globally to every migration, rules defined within it should have broad application-for example, mapping the share where reports will be saved or banning the transfer of certain music or video file extensions disallowed per company policy. A secondary Session Policy file is for rules that can be applied to specific migration actions. 

Via policy, I found that I could dictate whether the migration would move only files, or add settings or applications, as well. I could map network shares, and I could dictate which existing local users and profiles got migrated to the new computer. I could create exclusion lists of directories or file extensions to bar from transfer, and I could granularly include or exclude applications from transfer.

Unfortunately, the only way to dictate migration policy for applications is to identify the application ID by hand or list the application name (which would not be effective if trying to exclude migration of certain versions of the same application). 

I could also centrally dictate how a migration occurred-whether the transfer was done directly over the network or via a direct USB or LapLink cable connection between PCs, or whether the migration data got saved to removable storage or a share for later deployment. 

I could also set policies that defined which users or machines were allowed to use the policy defined in the upgrade action-to limit who performed migrations and which machines could be migrated. Unfortunately, this capability isn't tied into Active Directory, so I couldn't leverage existing domain security groups or Organizational Units within the policy. (I had to type in login names instead.) 

Via policy, I could also control the amount of interaction the users could have throughout the data collection process. Administrators have the option to granularly allow or deny users the right to override any of the default collection rules defined in a policy. 

I was impressed by this wealth of options and controls over the migration process, but I found the Policy Manager a little hard to navigate. Once I'd created the Master Policy and a few targeted Service Policies, it was difficult to tell which policy I was working in at one time and easy to make changes to the wrong policy. Existing policies are displayed in a Recent Policy pane in the middle of the console, but the actual policy under edit is shown at the top in the title bar. Instead of double clicking a policy to edit, I had to highlight it and then click an indistinct Open Policy hyperlink down below.

With policies defined, I could define a migration pair using the New Migration wizard. I enumerated the source and target computers, and defined which Session Policy to use for the pair. I could also forgo the use of a Session Policy, and either automatically apply default answers or prompt the user for every bit of information. Given that every transfer pair needs to be explicitly defined by repeating this step, and that each pair creates its own policy item that shows up in the Recent Policy dialog, the tool may not scale well visually or logistically to very large networks.

The PCmover Client can be run by the end user by e-mailing them a link to the executable on a network share, or the client can be triggered via script or by third-party enterprise software deployment tools.

IT administrators should be wary of LapLink's licensing and activation processes when using PCmover Enterprise. Whenever the PCmover Client is run on an originating host, the executable will take the proffered licensing data and activate over the network by default. I found that if the data collection and transfer doesn't take place for whatever reason, the activation still counts against the license total. With the licensed activations consumed, PCmover Client presents a license error that stops the migration process completely.

In the future, I'd like to see LapLink add license management reporting tools to its enterprise console, especially as migration projects will stop dead in their tracks if licenses get consumed faster than anticipated.

Senior Analyst Andrew Garcia can be reached at agarcia@eweekcom.