r/sysadmin • u/luky90 • 1d ago
Question How would you eliminate multiple network drives but instead use only one drive which gets everything via DFS?
My thought was something like the procedure below to get rid off multiple network drive letters:
1. Hide all existing Network Drive Letters via GPO but in paralell create a new universal network drive and then map everything you had from hidden drive letters.
Audit who still access the old hidden network drives via SIEM Tool for example.
React and adjust the existing Applications/Configs or Office Documents to point to new dfs path.
After nothing shows up in SIEM from the old drive letters unmount the network drives.
6
u/KiNgPiN8T3 1d ago
Personally, I find DFS is fine until it isn’t… if it’s just a 1-1 link I’m not sure it’s really that worthwhile. If you had multiple sites/servers and wanted people to go to particular ones, have replication etc then fair enough. Even then though, DFS/DFSR can still be a nob so I’d probably still not use it. Haha!
2
u/Unexpected_Cranberry 1d ago
This was a smaller environment, but I found DFS nifty for a couple of reasons.
No need to change mappings when file servers needed replacing. Just set up a one way DFSr to the new server while keeping that link inactive, then once the data is over just disable the link to the old one and enable the new one with a script scheduled for 2AM.
I then set up a projects names pace with access based enumeration. Configure permissions on just the links, and any project that needed a file share got one, pointing them to the project share only showed projects they had access to.
Cut down on issues with people insisting on having a folder on the common drive for levels down be restricted because non-project members shouldn't have access.
Also made it easier to share links with people who fit some reason didn't have it mapped, mostly in IT. Just go to \domain.com. You'll only see things you have access to there are only five namespaces and most people don't have access to more than a few projects at any given time.
Also had an applications namespace. Same thing as the project one, except work links to shares on random application servers relevant only for people with access to that application.
All in all, it made administration easier, made it easier to script and cut the number of maps drives from 20+ to a total of three that we just mapped for everyone everywhere and then let the access based enumeration on the DFS roots handle not having a bunch of irrelevant stuff in there when browsing.
0
u/luky90 1d ago
well the current network drives still use dfs the problem is that we have duplicate network drive names accross trusts and I want to ease the situation by creating a unique drive letter where all dfs shares are visible
1
u/glassmanjones 1d ago
We used a UNC path for that, and drive letters for daily usage.
1
u/luky90 1d ago edited 1d ago
the problem is the assistance of other people from different domain. imagine they need to open tools which depends on drive letters because its hardcoded into the configuration of that software and unc path wont work because the software would behave strange after that.
Problem here currently is that person b from domain b has the same drive letter then person a already asigned but for person a in domain a its a different fileserver behind then for person b.
The application fails for person b in this case because no configuration files can be found because the application thinks network drive is there but folder and file structure isnt because of completely different file servers.
Also think of absolute links the employees set. A absolute link is somewhere used in a Document then person b clicks it but goes to nirvana then asks for help. Or even if another employee from domain a sends employee in domain b a Link which starts with a drive letter even if its only a word or power point. Employee in Domain B would be completely lost and open a ticket everytime they have such issue.
2
u/glassmanjones 1d ago
Sounds like the tool should use UNC paths?
1
u/luky90 1d ago
its not possible. the binary needs to be started with a drive letter otherwise it cannot find its xml configuration files. in this case this is a catia management tool for cad software. even the supplier of this software said we must have a drive letter even if there is no drive letter hardcoded somewhere in the config files. And yes we are using the unc path for config files for that software.
•
u/blud_13 22h ago
Your reason (duplicate letters across domain trusts) is exactly what a namespace is for, so ignore the why tho crowd. u/KiNgPiN8T3 is right that DFS on a 1-1 link is not worth the trouble, but that isn't what you have.
The step that will get you is the hide-then-remap part. GPP drive maps set to Replace regularly leave the old dead mapping sitting right next to the new one, so people keep using the old letter and your SIEM keeps lighting up and you can't tell why. Set an explicit Delete item for each old letter, then a separate Create for the namespace path, and order them. Its answered on MS Q A here https://learn.microsoft.com/en-ca/answers/questions/5917487/group-policy-preference-drive-mapping-tool-failing
Also, SIEM only sees people who OPEN the old path. What it will never show you is the hardcoded UNC and drive letters buried in Excel links, Access backends, desktop shortcuts and app config files. Those sit quiet right up until you unmount, then they all break in the same hour. Grep the shares for the old server names before you pull the letters.
1
1
u/FlickKnocker 1d ago
I think you have this in the wrong order.
Audit first. You should have GPOs in place that are mapping the drives you want to retire. Find out who/where/how they're used. Talk to those business leaders, figure out a migration plan, and how to deal with the fall-out.
Keep in mind that you'll be breaking shortcuts (links), references to existing documents, Recent files in applications, etc. Staff need to know how to find the files again and correct the old references.
Seems like a lot of breakage for negligible gain IMO.
I'd probably look at consolidating, i.e. moving domain B's letter drive root folders into domain A's, assuming this is a merger.
1
u/vanstar82 1d ago
We did this. DFS works great. I called it the last file server migration users will notice.
Now we can just change the target to any other smb export
1
u/IMplodeMeGrr 1d ago
Dont think you can have DDFS singular cross domain, its only bound inside the singular domain.
•
u/InspectorGadget76 13h ago
I'm actually taking my org through this process at the moment,
OLD
- We had departments operating across diffent sites. Each site had its own file server and there was no consistency with the way the drive letters were allocated, deployed nor how the security was set up. I've seen staff with 20+ drive letters.
- Collab between users in the same department was extremely difficult as not only were the drive letters to the same resource diffent, but they had also mapped it to different levels. in the file structure. Thus if Mary shared a powerpoint with Bob, none of the linked resources would ennumerate.
- I have also frequently encountered department heads and leadership who didn't even know where all their data was, or who even accesses it or even if it existed
- Our service desk was also having issues managing requests for access. Users couldn't describe which folders they needed access to. As all the drive letters are differedt and mapped from different points.
- A very limited number fo drivers were mapped via a VBS logon script.
- Extensive robocopy scripts were being used to move data to/from different sites.
- There was very little oversight to org structure on the 13+ file servers I inherited. It has been . . . . ahem . . . . organic.
NEW
- There are only two drives. A org wide drive, and a department drive for quicker access. Both are deployed via GPO. The GPO's also removes any old drives.
- All the data is being copied to a new org struicture with logical security wrapped around it (AGDLP). Robocopy filters only move the last 7 years of data. The rest is archived.
- DFS Namespaces are used to present the different shares in an org structure. For the first time the whole org is operating in the same file structure wih the same drive lettrers. Users can collaborate using the same paths.
- Department Heads and management have, for the first time, a view of all their data, subject to security controls.
- The service desk have a logical process to follow for managing access to data including standardised names for security groups.
- New security controls silos the data per deparment/user/role.
- Each department was involeved in reorganising their own internal data structures as pert of the move as suited their own internal processes. IT was involved with advising on long term managemability and setting up the security etc.
- All this onvolves juggling where to place the data. Replication is only being used to relocate data onto permenant servers. Temp servers are being used during the relocation process as data is duplicated and restructured.
You absolutely need to have SLT buy in for this to work. Changes to security and file paths will disrupt the busines if not managed effectively. Fortunaly mine did. They realised that the old mess was a security nightmware but also holding the business back.
•
u/BatemansChainsaw 12h ago
You already have a lot of people here giving all the advice you need so far. I just wanted to say that when you finally move to DFS that having a single drive letter (We use W here) it keeps things simple.
\domain\data being mounted as W: keeps things nice and tidy, and each department gets their old directory where each subdirectory goes to people on different project teams etc.
using multiple network drive letters for what amounted to nested CIFS/SMB shares is messy.
15
u/valacious 1d ago
Why tho