Hardcoded UNC paths and system upgrade/migration

Having just replaced an ageing NT server with a shiny new box, the data
migration went smoothly, the domain-migration of the computers was
painstaking as usual but worked.. but the thing which virtually doubled the
projected install-time was the presence of numerous hardcoded UNC paths to
the old server within several apps on the desktops. Finding the cause, and
fixing this single problem took substantially longer than installing and
commissioning the server itself.

What's more we couldn't have done much to anticipate the problem, as the
hard-codings were inside of non-text config files. I think it's also
reasonable to assume that the NT box's installer applied (what I would
consider to be good practice) and used drive-mappings, but the apps
themselves automatically changed these mappings to UNC paths, without his
knowledge or consent.

We needed to keep the old server running until the email software had been
transferred, so keeping the same name was not an option. Not that we'd want
to call the new box "NT" anyway, so a name change was more-or-less mandatory.

It seems to me that in promoting the use of hardcoded UNC paths, Microsoft
is advocating a practice similar to hardwiring computers to hubs/switches
instead of using structured cabling. Quick and dirty at the time, but you
come to regret it later because you're unable to change anything without
ripping the whole thing down and starting over.

Noticed another post in here relating to a similar issue, and wondered what,
in general, the system-installers do about it.




Anteaus

Anteaus,
Its an interesting observation. I think it relates more to migrating old
systems than to current practice. DFS Namespace provides a good way to get
around hard-coded paths. If the application can use UNC it can use DFS, so
there's really no good reason not to use it. It doesn't help you migrate
from old hard-coded paths, but it saves anyone having to do it again.
Anthony,
http://www.airdesk.co.uk/deployment.aspx



"Anteaus" <(E-Mail Removed)> wrote in message
news:F29998E6-6BEA-4A29-BBBF-(E-Mail Removed)...
> Having just replaced an ageing NT server with a shiny new box, the data
> migration went smoothly, the domain-migration of the computers was
> painstaking as usual but worked.. but the thing which virtually doubled
> the
> projected install-time was the presence of numerous hardcoded UNC paths to
> the old server within several apps on the desktops. Finding the cause, and
> fixing this single problem took substantially longer than installing and
> commissioning the server itself.
>
> What's more we couldn't have done much to anticipate the problem, as the
> hard-codings were inside of non-text config files. I think it's also
> reasonable to assume that the NT box's installer applied (what I would
> consider to be good practice) and used drive-mappings, but the apps
> themselves automatically changed these mappings to UNC paths, without his
> knowledge or consent.
>
> We needed to keep the old server running until the email software had been
> transferred, so keeping the same name was not an option. Not that we'd
> want
> to call the new box "NT" anyway, so a name change was more-or-less
> mandatory.
>
> It seems to me that in promoting the use of hardcoded UNC paths,
> Microsoft
> is advocating a practice similar to hardwiring computers to hubs/switches
> instead of using structured cabling. Quick and dirty at the time, but you
> come to regret it later because you're unable to change anything without
> ripping the whole thing down and starting over.
>
> Noticed another post in here relating to a similar issue, and wondered
> what,
> in general, the system-installers do about it.
>
>