Better Process for Catalog Move
Created: 17 Aug 2009 | 1 comment
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.
idea Filed Under:
Comments
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
Would you like to reply?
Login or Register to post your comment.