|
First of all, thanks for the input we received sofar. As we're not moving to a similar structure, we still
need to find all the linked files and update them. At first it seemed that the LU.exe tool wouldn't work,
however, here's a nice little trick you might want to try: LU.exe \\Servername1 \\
\\ /r /t=100 The two \\'s after the \\Servername1 are supposed to be source and
target paths. Leaving these empty will give you a clean list of all the files
that have links and which links these are. After that you can update to your
heart's desire. Hope this helps someone in the future. Regards, Paul. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Grillenmeier, Guido you can also consider
using DFS consolidation roots for an interims time during the file-migration
(see Q829885 - Distributed File System update to support consolidation roots in
Windows: http://support.microsoft.com/?id=829885).
This will leverage the OptionalNames regkey (a little more restrictive
than DisableStrictNameChecking). btw, the DFS
consolidation roots will soon be supported by the Quest server-consolidation
tools (and not only by Microsoft's FSMT... - which sad, but true, doesn't
support migration of local groups and thus cause issues consolidating data
ACL'd with local groups). /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Note that if you do decide to use CNAMEs to
redirect CIFS/SMB queries to servers using a.n.other name, you must configure
DisableStrictNameChecking in each of the server's registries. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters -- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacqui Hurst If you are keeping the same file structures
and just changing the server names can you not setup cnames in DNS to point to
the new servers? Not tried it myself but thought it might be
worth a suggestion. Jacqui From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Paul van Geldrop Hi
all, A bit
offtopic, I realise, but hopefully somebody will be able to provide an answer. The
problem: We're on the verge of consolidating a rather big load of user files to
a new environment. However, we'd like to avoid the pitfall of linked files, for
example, OLE links on Office documents and such. Say that we're moving a
document from server A to server B and the document has a link to another
document on server A. That other document we also move to server B. The link in
the file is, of course, not updated, and errors have their wicked way. To
prevent this from happening, we'd like to scan the different volumes for files
that have links to other files and get a clear report. We
examined the Link Updater (lu.exe, Quest Software), but that utility requires
you to enter the source and target path of the linked files and doesn't accept
wildcards, so that won't quite do the trick as we don't know those paths,
that's what we're trying to find out. Anyone
who might be able to give a handy pointer in the right direction for a tool
like that ? Thanks
in advance, Paul.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. |
Title:
- [ActiveDir] OT: Linked files. Paul van Geldrop
- [ActiveDir] OT: Linked files. Lucia Washaya
- RE: [ActiveDir] OT: Linked files. Lucia Washaya
- RE: [ActiveDir] OT: Linked files. Paul van Geldrop
- RE: [ActiveDir] OT: Linked files. Lucia Washaya
- RE: [ActiveDir] OT: Linked files. Jorge de Almeida Pinto
- RE: [ActiveDir] OT: Linked files. Lucia Washaya
- RE: [ActiveDir] OT: Linked files. Justin_Leney
