At login it takes minutes before mapped drives (H:, S:, P:) appear, and some show with a red X.

Drive mapping at login against a slow or unreachable share blocks everything that follows. With persistent reconnect, async GPP mapping and better fail-fast, the experience is usually tolerable within a week.

Try this first

1. 1Test share reachability outside login: 'Test-NetConnection servername -Port 445' in PowerShell. No connect or high latency means the issue is network or DNS, not mapping.
2. 2Replace 'net use' in login scripts with GPP Drive Maps. 'Reconnect' on for persistent mapping, 'Run in logged-on user's security context' on as required.
3. 3For shares behind VPN: item-level target on a specific subnet or DNS name, otherwise the client tries an internal server while at home.
4. 4Disable persistent Windows mapping for shares not always needed. A drive you never touch still costs reconnect time.
5. 5On Windows 10/11, keep 'AlwaysWaitForNetwork' off (computer policy 'Always wait for the network at computer startup and logon'). Async maps then don't block shell start.
6. 6Document who needs which share. An audit usually finds three shares still mapped for departments that no longer exist.

None of the above fits?

Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.