Deployment Solution

So we recently moved our software share that we used for deploying all of our software from with a shiny new DFS share. For the sake of speed and sanity I'd like to directly manipulate the database to replace "\\servername\sharename" with "\\dfs\sharename". Has anyone ever done this before or see any problems doing so?

I've found the few relevant tables that need to be updated:

[script_task]; column: script, script_file

[copyfile_task]; column: local_file

svs_manage_layers; column: file_path

Install_task; column: install_file, addl_cmd_line, cmdline_params

And here's an example of the update SQL script:

UPDATE script_task
SET script = REPLACE(script,'\\servername\sharename\','\\dfs\sharename\')

 

My DBA had also mentioned we need to change ‘script’ column in the ‘script_task’ table to allow for 6075 varchar, it is currently 6000. I'm not sure if one of run script jobs has a really long vbscript in it so I'm not sure if it would be a good idea to change the character limit, probably best to just find the long script and fix that.

 

This would save me a ton of work, we have the old share name aliased to the new location but I'd like software to be installed using the new path so the install source is correct in the registry and maybe 5 or so years from now we can remove that alias. Obviously we'd perfrom a DB backup and a job export before performing the work.

I'd leave the alias in place, then all your install sources can be kept correct the next time you change where the software is deployed from.

I plan on leaving the alias in place for at least 5 years to match our hardware refresh rate but I'd like to have a plan to one day get rid of the alias which I can't do if we're still deploying software from that path. I have at least 4,000 places that path is referenced in jobs/tasks/software deployments so doing it manually isn't really an option unless I can get an intern :)

The thing is, if you get rid of the alias and use "dfs" as the path you'll have the same problem all over again when you replace "dfs". I can't see the benefit in getting rid of the alias.

If you really want to do this, then the answer is simply "yes" -you can used use the T-SQL update commands to replace the UNC paths. I've done this many times and it's perfectly fine.

One thing that does worry me though is the DBA citation of a need to increase the character limit on the script column of the script_task table to update these UNC paths. The "script" field is used for embedded scripts which do not reference source paths. If this change is made it will push you out of support as well as possibly effecting the operation of job exports and imports (and these possible impacts are just those that are coming from the top of my head). So, tread carefully here and make sure you and your DBA are happy before proceeding.

 

 

I've seen a few places that put UNC paths in embedded scripts. There is a character limit on embedded scripts, probably related to the database column limit but probably enforced by code somewhere, so if you use T-SQL to change the scripts and exceed the limit you may not be able to view or use them properly.

Thanks Ian. I'm going to test this as part of my transition to a brand new server for GSS I'm working on building. If I blow up the DB somehow at that point it's not a big deal at that time as I can restart from scratch.

I just checked and luckily the new DFS path is the exact same length as the old UNC path :)