This information is obsolete for current versions of FileHold.
Active Directory Lightweight Directory Services (ADLDS), also known as ADAM, is a key component of all versions of FileHold up to and including FileHold 14.2. This article provides some information on managing ADLDS for installations that plan to manage or move ADLDS directly. These steps are not normally necessary for normal day-to-day FileHold operation.
Export / Import Objects Overview:
- This utility allows you to manually export a file formatted with XML that contains all user and group objects for your system. It also provides the ability to import a file, although a specific procedure is needed for this.
- This file contains the same type of information as the file created nightly via automated scheduled task "FH backup ADAM objects" which runs nightly at 12:55 AM on the FileHold Server.
- However, when recovering from disaster with backups - the file that is closest to your date/time SQL and FileHold Data backups in terms of time / date is one that you would want to use. If the user/group contents of this file do not match up, then the recovery will be problematic.
- When FileHold personnel perform migrations from one server to another, FileHold personnel run this tool to do a backup of the latest information in the FHURM > LDS Instance, and then migrate over databases, db log files, FileHold Data directory and the user/group objects contains in the file created by this procedure. This file is then restored using a specific restoration procedure.
- The FHURMBackups folder within the FileHoldData folder are for disaster recovery purposes when you are restoring a system completely from backups.
- The 3 procedures on this page, which include Export Objects, Import Objects, and Restore ADAM - will cover various scenarios around backup / recovery and migration of ADAM objects from one server to another.
Step 1: Choose Export Objects and Start
To run this tool your Windows account will need to be a member of the local Administrators group.
Specify a destination file location - and you can even name the file beyond the default name. We recommend adding a date to the file name.
You should keep this file somewhere safe, but it can only be used when databases and the FileHold Data repository are all from the exact same time frame.
This utility is very simple to use, but involves a procedure for locally managed users only - if you have an AD Synchronized system - then you should absolutely not use this procedure.
If you wish to use this to restore MS ADAM from Backup then you can use this procedure.
- If you are restoring Databases, and the entire FileHoldData structure including Document Repository, FullTextSearch and FHURMBackups, then you should use the latest file from the FHURMBackups folder that is within the FileHoldData structure for this procedure.
- WARNING: Make sure this is the same date/time period as the backups for your Database and FileHold Data directory structure.
- If you are migrating from a Windows 2008 x64 system to a different server, then you can Export out the ADAM objects and then use that file for this procedure.
Follow all steps described in the Backup and Recovery guide on recovery before starting this procedure, but when you get to the step on restoring ADAM, you can use a tool like Symantec Backup Exec to restore that folder structure - by following the procedure - OR - you can use the procedure below. When you are migrating from one server to another, we find this procedure works very well.
- Export ADAM Objects using the tool and procedure described in this article
- Ensure FHURM Service is running
- Stop the FH App Pool
- Remove ADAM by navigating to the C:\Windows\ADAM folder as a server administrator and execute the following command line:
You will be asked if you wish to continued, click Yes to do so...
Follow the prompts to remove the MS ADAM Instance - once complete, you will need to install a default ADAM instance, and then restore / import the ADAM objects.
Follow the examples below - filling in your domain\service-account or server\service account information
Click Install to create a default, blank instance
Once complete - then move onto importing ADAM Objects
Stop WWW Service, then click all 4 check boxes. Ignore Step 2 and Step 3 for this procedure (this screen shot is due for an update and removal of those steps)
- Point to the backup file made by scheduled task - OR - the export data wizard - depending on the situation (system recovery or migration to new server)
- Fill out the new password for the System Administrator account. All Local user passwords are reset according to a pattern, since none of the passwords are recoverable in any way.
- A password change log file is created as part of this process, you decide where this file should go. We recommend opening it in a good text editor or in MS Excel as needed.
- You can also force password change for all users as part of this, it is checked by default.
- Specify Database connection settings
- Your Databases from your SQL backups must be restored over the default databases if you just freshly installed FileHold, or the Databases and Log files from the other server you are migrating from must be properly attached and given DB Ownership to the Service Account to all 5 databases.
- These production databases must be migrated or restored to your FileHold server before continuing!
- Finally, you can click Import - this can take a minute or two.
- Once complete, you can log-in with the "sysadm" account
- Then the Health Checker should be run on the server to validate all steps in your migration are running correctly.
- The Document Repository, Full Text Search Collection, and FHURMBackups folder should all be in place
You should then carefully check basic functions of FileHold in terms of:
- Check Cabinet and Folder memberships
- Check Schema memberships
- Add a file, check out a file, check in a file, search for a file. complete a work flow
- Distribute passwords to users, or reset the passwords in Web Client > System Admin > Manage Users.