Hi there! I'm trying to get to the bottom of a mystery regarding a network drive that's automatically being mapped to K: on some of my users' PCs. I know where this drive points to, but I'm unsure about what's causing the mapping to happen in the first place. Here's what I've done:
- I checked one user's machine with 'gpresult /h' but couldn't find any Group Policy Objects (GPOs) responsible for the mapping or any scripts that might be running it.
- We do have a logon script in Active Directory (AD) for other network drives, but it's not linked to this K: drive in question.
- After inspecting the server hosting the share, I didn't find any scripts responsible for this.
To complicate things further, I tried deleting the mapping for a test user, but it reappeared the next time they logged in. I'm sure there's a straightforward reason for this, but I'm running out of options. Any thoughts or ideas would be really helpful!
5 Answers
Also, check the AD profile for any home folder configurations. That’s often a culprit when drives are mapped unexpectedly. It could be that the K: drive is set as a home folder for some users, which might not show up in a typical script check.
One approach is to have a user log into a different computer that they haven't accessed before. If the K: drive doesn't get mapped there, it might suggest a stuck GPO on their usual PC. This could clarify whether the issue is domain-wide or isolated to specific machines.
Great idea! I’ll test that out. I just worry because the server hosting that share is being decommissioned soon, so I need to pinpoint where this mapping is coming from.
It might also help to check for any local startup scripts or batch files that could still be lingering and mapped the drive long ago. Sometimes admins leave these behind unintentionally, and they don’t always play well with newer systems.
That's a great point! I need to double-check local profiles because these could bypass AD settings entirely. I'll give that a look!
Another angle is to check if there's a task running in the Task Scheduler that could be triggering this mapping. GPO modelling could also unveil policies that might affect the users, so it’s worth a shot if you haven't done that yet.
I haven’t yet explored Task Scheduler, but I plan to dive into that next. Thanks for the suggestion!
You might want to explore the local security logs on the user's machines and even at the domain level. Hanging out in those logs can sometimes reveal hidden drives mapped by policies or scripts you haven't caught yet.
I've been digging into the event logs but haven’t had success finding anything. If you have specific EventIDs in mind, I'd appreciate the guidance!
We do have a separate home folder mapped to another letter for all users, and the logon script doesn’t reference K:. So I think we might be looking at something else entirely.