Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

Better Process for Catalog Move

Created: 17 Aug 2009 | 1 comment
dustin_yonak's picture
9 Agree
0 Disagree
+9 9 Votes
Login to vote

In the case of reaching disk capacity on the NBU install volume it's often recommended by support to move the NBU catalog to another volume. The current process can be reviewed in the Admin Guide, it's a very manual process that includes the creation of touch files and has to be done on a per client basis. It would be nice to see this functionality moved into the GUI and writing the locations for each client's image database directory into the EMM database to avoid the usage of touch files.

Comments

Tomer Gurantz's picture
27
Aug
2009
1 Vote +1
Login to vote

Agreed. However...

For UNIX master servers this isn't an issue with symbolic links, which are trivial to create.

For Windows master servers this process is excrutiating. As dustin_yonak mentions, you have to create touch files, but specifically one for each client!

One way to work around this is by using a "junction point" (effectively a Windows mount point), which is also trivial to use to move the entire "image" folder elsewhere from the system disk. That said, most people don't use Junction Points and Microsoft doesn't exactly make them very visible and easy to report on (in comparison to drive letters).

I disagree with the EMM database suggestion above, as then the Master server would have a dependency on that to get to its images, which is a dependency it currently doesn't have. The EMM database is for media and device management, really.

The easiest change would be to allow a touch file in the root folder of the images directory, so that you can move the lot, instead of client by client. Currently I don't think you can do that (at least the last time I tested it in 6.x somewhere).

Another option would be to allow NBU to possess a setting for the database root path or images root path so you can have a custom location listed. That said, it wouldn't jive with old versions of the product and the fact that currently everyone knows exactly where to go for this information.

Another thing to keep in mind is that the images database may at some point be: 1. in a relational database (?) or 2. indexed more appropriately for search. If either of these are happening and causing changes to these database locations, that would be a good time to change the method of moving them as well.


Principal Learning Consultant with Symantec Education Course Development