Server Administration > Workflow to Manage Process and Change > Testing Workflow With Admin Migration Wizard > Managing Administrative Locks
  
Managing Administrative Locks
Locking a server means that the server is no longer editable directly through the standard command set. A locked server can be a production server (or a test server in a two-stage configuration). The migration wizard requires that the production server be locked before it can start any migration operation. Locking ensures that no changes can be made during the migration or at any time while the staging server is bound to the production server.
* 
As administrator, you can also manually lock either the staging or production servers, or both, to prevent administrative changes from taking place. Locking both servers means that no one can make any administrative changes to the workflow and document system unless they are using the Admin Migration Wizard.
It is important to understand that an administrative lock cannot be used to prevent other administrators from making changes so that you (the owner of the lock) can make changes.
Creating a lock binding is the act of linking one server to a lock on another server. When a lock binding is created, the production server records the host name and port of the staging server.
* 
You cannot bind two different staging servers to the same production server.
Do not break a lock when a migration operation is in progress.
A lock binding cannot be directly created by an administrator. It is created automatically when the staging server has initialized and successfully verified that it is synchronous with the production server.
If the connection between the staging and production servers is lost for any reason, such as a hardware or network failure, the lock remains on the production server and the staging server continues to act as if the lock binding relationship is in place. If the migration wizard is started while the communication between the two servers is still broken, then the system posts an error. You cannot then run the migration wizard until the problem has been resolved.
To avoid the possibility of any administrative changes occurring while the staging server is being brought on line, you can also manually lock the production server before setting up the staging server. If the production server is locked when the staging server initializes, a lock binding is still created.
You can perform some administrative changes on a locked server, if required. Use the following properties to allow these administrative changes:
mksis.im.allowPrincipalCreationOnLockedServer
Enabling this property allows you to create and import users and groups on a locked server.
mksis.im.allowProjectModificationOnLockedServer
Enabling this property allows you to create and modify projects on a locked server.
mksis.im.allowDynamicGroupModificationOnLockedServer
Enabling this property allows you to create and modify dynamic groups on a locked server.
* 
The Admin Migration Wizard automatically imports users, groups, projects, and dynamic groups into the staging server (or test server in a two-stage configuration) from the locked server when you run the migration wizard.
When using the migration wizard for importing these admin objects from the locked server, note the following:
If the migration wizard detects new admin objects with identical names on both the staging and locked servers, then they are mapped together and the differences, if any, between these objects are displayed.
If the migration wizard detects that the new admin objects on the locked server do not have identical names on the staging server, then the new objects are created on the staging server (or test server in a two-stage server configuration). These new objects are mapped with the objects of the locked server.
In the GUI, locking and unlocking are available through the shortcut menu.
If a Windchill RV&S server administrator attempts to break a lock on the production server, a warning message indicates that breaking the lock invalidates any work that is currently being done on the staging server and that the staging server must be re-initialized. E-mail notifications are also sent, provided the appropriate properties have been configured.
* 
Releasing the lock on the production server means that the lock binding between the staging server and production server is lost and the two servers are no longer synchronized. Further staging work, therefore, requires a new copy of the database from the production server.
You can also control server locks through the CLI using the commands for im obtainadminlock, im releaseadminlock, and im viewadminlock. For more information on using these commands, see the CLI man pages.