Our login scripts map drives, hook up printers, push group policies. For some users it takes 90 seconds before the desktop responds.

VBS or CMD login scripts are usually sequential and hang on each slow share or print server. Using Group Policy Preferences plus some parallelism, you offload ten-year-old legacy.

Try this first

1. 1Inventory what the login script does today. Drive mappings, printer hookups, registry tweaks, file copies. Write it down, otherwise you'll accidentally break something one department relies on.
2. 2Replace drive mappings and printer installs with Group Policy Preferences (GPP). GPP runs async and supports item-level targeting (per security group or OU). Scales much better than 'if memberOf' in script.
3. 3Slow steps that must stay scripted: wrap them in 'start /b' (Windows) or run as async PowerShell jobs. The user doesn't need to wait for the print server ping.
4. 4Enable synchronous foreground processing only where strictly required (folder redirection first setup). By default policy can run async: Computer Configuration, Administrative Templates, System, Logon, 'Always wait for the network at computer startup and logon' = not configured or disabled.
5. 5Measure with gpresult /h and the Microsoft-Windows-GroupPolicy/Operational event log. You'll see per CSE (client-side extension) how many ms it took. Tackle the top two first.
6. 6Document what remains. Put an expiry date on every rule, otherwise mappings to long-dead fileservers linger 5 years from now.

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.