Editor's Note: It's very important to realise that this is not a magic bullet: it should only ever be considered as a last resort. A lot of data would still be lost with this process, for example data that is customized for your environment, such as auxiliary files and custom reports. Novell Support has used similar techniques in the past, but there are usually still some "odd" problems remaining.

The File Store in ZENworks Asset Manager (ZAM) is a very key part of the process. The Collection Servers all use the File Store, and all the Client Agents that talk to Collection Servers indirectly rely upon it. Corruption or outright loss of the File Store can have major impacts to the Inventory process as a whole. This article should help you get it back if you find you need to rebuild your File Store.

• Understanding the File Store

• Rebuilding the File Store
  
  
• Install the Temporary Database

• Install Asset Management

• Apply the PRU update

• Update Production with the PRU

• Make sure it works!

Understanding the File Store

The File Store is the place where ZENworks Asset Manager keeps many things:

• The files used by the Client Agents to identify software.

• Updated executable files for the Client Agents

• The files the Collection Servers cache to distribute to Client Agents

• Tracking Product Recognition Update (PRU) patches

• Tracking Live Update software updates

• Files the Web Console uses

Figure 1- The File Store directory



The Collection Servers do the most interaction against the File Store. On start-up they cache all of the files they ultimately send to the Client Agents assigned to it, which you can see in the [install directory]\Bin\Cache\ directory.






Figure 2 - The Collection-Server cache directory



When the Collection Servers do this, they also validate the files against checksums stored in a catalog in the database. If the files do not pass checksum validation, the Collection Server will not inventory clients. Therefore, if these files get corrupted or go missing it can halt all inventory activities.



Also on start-up, the Collection Server will check to see if its software needs updating. Unlike the Client files just described, the flag that indicates that an update has already been applied is stored in the File Store and not the database. Checksums are not validated for these files.



When a Product Recognition Update (PRU) gets applied to an Asset Manager deployment, several files get updated in the file-store. Also, the date encoded in the PRU is stored in the database. Collection Servers periodically check for updated PRU files to cache for deployment to clients.



Because of how much effort it takes to rebuild the store once it is corrupted, it should be included in a regular backup rotation. Changes to the File Store happen infrequently, but restoring from backup is easier than having to rebuild it.

Rebuilding the File Store

Unfortunately, there are no tools designed to rebuild a store for you. This has to be done manually. The steps can be summarized into several stages:

• Locate a database server that can host a new temporary ZENworks database.

• Do a fresh install of Asset Management against this database, pointing the file-store at where you'd like your production File Store to be.

• Apply the last PRU applied to your production database, to your temporary database.

• Apply the last Live Update applied to your production database, to your temporary database and Manager.

• Log in to your production database, and follow the steps in TID10099399 to force a re-application of the PRU you applied to the temporary database.

• Start up your production Collection Servers.

This all assumes that you've just lost your File Store, and your database is intact.

Install the Temporary Database

The first step is to find a spot to host a new database. This can be a separate database next to your production database (e.x. "ZENWorksTemp"), a database on your Development database server, or use something like SQL Server 2005 Express (MSDE for SQL Server 2005) on a server and deploy to that. This database should never be involved in inventory so size doesn't matter. We only need it to get the File Store into a state where Production can use it again.



Keep in mind that even a database with no workstations in it can be a bit sizable. A database-file size of 100MB and a transaction-log size of 200MB can be expected. When installing your database, or creating the instance for it, keep this in mind. It may make the installation process go a bit faster if the DB engine doesn't have to extend data-files in the middle.

Install Asset Management

The next step is to install Asset Management to the temporary database. During the installation process it will create the File Store. Point it at where your production file-store should be. There is no risk in this, as any Collection Servers will not use this data because these files will fail checksum validation.



The only component beyond the base you need to install is the Manager. You will not need a Collection Server, Task Manager, or Web Console as part of this process.

Apply the updates

The next step is to apply a PRU update to the temporary database and the File Store. The process for this is identical to how you do it in production, so follow that. Either download the update yourself and apply it, or let Manager do it for you from Administration -> Product Recognition Update. If possible, update it with the same update you last applied in the Production database. If you don't have that, you can apply the latest from Novell.



Then do the same thing with the 'Live Update'. This will cause the Manager to go through an upgrade cycle itself, but also populate the File Store with the correct code-level for production. If you are applying a newer Live Update than production, when your Collection Servers come back online for the first time, they'll update themselves.

Update Production with the PRU

At this point the File Store is rebuilt. Now we just need to get the Production database convinced of this fact. The way we do this is to apply the latest Product Recognition Update, forcing application if we have to. This process generates new client files based on data from the production database, which may contain customized data that the temporary database does not have.



To force a re-application of an already applied PRU, follow the steps lined out in TID10099399. For completeness, I'm including the bulleted steps. For a full description of why and how this works, read the TID.

1. Log in to Production with the Manager, and ensure that the Inventory Process is stopped.

• On the workstation running the Manager, set the following registry keys in HKLM\Software\Tally Systems Corp.\TSCensus\Manager\PRU (You may need to create the "PRU" key):
  
  
• DWORD: ReapplyCurrent=1

• DWORD: ForceFullApply=1

• Apply the PRU you applied to the Temp database to the Production database. This should force it to re-import.

• Start the Inventory process. This should force it to re-merge the PRU, and this will update the File Store correctly.

• Delete the two registry keys.

Make sure it works!

Once this is done, your File Store is now fully rebuilt. To make sure everything is on the up and up, stop the Inventory Process and turn on one Collection Server. If everything was done right, it should update itself if new software was applied, and should successfully cache files from the File Store. You can watch that process in the Logs directory, in the files named "ColSvrCoreEvent[date].log". If the Collection Server stays up, start the Inventory process. You know it worked right if the Collection Server stays up after Inventory is turned back on.



At this point the temporary database you created is no longer needed, so get rid of it as you see fit.