we are looking at how we can improve startup and login times, and in order to do this we have altered a some settings on a few workstations where we are monitoring login times to try and determine if they have led to an improvement.
The major improvement provided by these settings will actually be to startup rather than login, and is not something we can currently monitor unfortunately but which should dramatically improve startup times.
The settings that have been altered are:
- Disabling IPv6 on the workstation
- Setting workstations to not wait for the network before displaying the ctrl+alt+del screen
- Running startup scripts asynchronously rather than synchronously
- Running Login scripts asynchronously rather than synchronously
- Deleting user profiles after 5 days of inactivity rather than one day
For those that are interested, a bit more detail about these settings:
Disabling IPv6
By default, Windows 7 workstations use IPv6 as the default protocol, but the SHU network is currently IPv4 only. It is recommended in a number of places that if not using IPv6 then this should be disabled as this is the primary protocol before defaulting to IPv4. The caveat to this is that some Windows 7 services such as DirectAccess and HomeGroup do require IPv6 to be enabled. This doesn’t affect SHU workstations as neither are used within SHU.
The Network Team requested that we disable IPv6 on workstations a while ago because at some time in the future they will want to investigate using this within SHU and so don’t want to have MD workstations obtaining an IPv6 address and then having unspecified issues. All SLS Office and Adsetts workstations have been running with IPv6 disabled for at least a year without any issues being reported.
You can tell if IPv6 is disabled because if you do IPCONFIG, only an IPv4 address is shown.
Setting workstations to not wait for the network before displaying the ctrl+alt+del screen
We previously had to have this setting enabled to wait for the network due to using the Novell network, which could allow a user to authenticate with Netware before the AD was available.
This setting does mean that all Group Policy settings are applied during every startup before a user can login, which is good from a support point of view in that we know every setting and service is correct after a restart, but does take a considerable amount of time on some machines, especially machines that are not the latest hardware.
No having this does means that machines do not re-apply all Group Policy settings every startup, but this isn’t really necessary as it is very rare we apply new settings to Group Policy, and settings will still be updated during the normal schedule, which his 90 minutes plus 0 to 30 minutes, so effectively at least once within every 2 hours. The only real issue will be if existing machines are moved to another OU, or a setting is applied and required immediately which at present can be done by doing a restart. On test machines users can run GPUpdate of course to force a refresh, or use the context menu Mike has added to SCCM to force a GPUpdate on a remote machine.
This setting has been used within SLS for Office workstations for at least 6 months, which is why these Office machines get to ctrl+alt+del so much quicker than other machines. This setting is also applied to every laptop because otherwise when outside SHU the laptop would have extremely long startup times as it ‘waited’ for the network before it timed out, which obviously wasn’t present.
On machines with a lot of services that need starting before the ctrl+alt+del screen is displayed the machine can still be at the ‘applying computer settings’ for a seemingly considerable amount of time, but some software such as Visual Studio and NVivo start SQL Express services which does delay the startup process. We are intending to see if we can disable these services, or at least set to ‘delayed start’.
We have seen one issue with this setting though. 6 office machines within the same area all failed to move from dumpnet to the authenticated network during startup. This has never been resolved as to why and it was only fixed by ensuring these workstations also apply every setting and wait for the network before allowing the user to login so it is worth knowing.
Running scripts asynchronously
Scripts can either be set to run synchronously or asynchronously.
Running login scripts synchronously means that every script has to complete before the desktop is shown, which does add considerable time to logins. Asynchronously does allow explorer to start before all scripts have completed.
This is only the case for users who have profiles on the machine, if no profile exists then scripts are still run synchronously, which will be the vast majority of student logins so probably won’t have much effect for student logins, but does improve office login times.
At present all scripts are set to run synchronously unless in a test group but I intend to widen the asynchronous testing shortly.
Deleting user profiles after 5 days of inactivity rather than one day
On Lab machines, all profiles are set to be deleted during the next restart after 24 hours of inactivity.
Users logging in to a machine where they have logged in previously have a quicker login because the workstation does not have to create a new profile during the login process, and if the setting is used, login scripts can run asynchronously.
By setting the setting to 5 days, if users re-visit a machine within 5 days they will have a much quicker login, but this does mean the workstation will have more user profiles available and could potentially fill the disk if there isn’t much free space.
It has been suggested that we alter this to 8 days so that students in weekly lectures if using the same workstation would have improved login times.
Office machines do not delete profile directories.
Locations where various settings are being tested and login times are being monitored:
Disabling IPv6, not waiting for the network, running startup and login scripts asynchronously and leaving profiles 5 days:
Adsetts: 6624, AC03-003 to AC03-006, AC04-044 to AC04-061, AC05-108 to AC05-115
Arundel: 10001-01 & 10001-02 (Standup / Touchdown machines in café)
EMB: EMST-001 to EMST-010 (Standup / Touchdown machines)
Furnival: CAST-001 to CAST-006 (Standup / Touchdown machines in café)
We do intend to rollout these settings wider, initially to all Standup machines but hopefully all machines in the near future if no issues are reported.
A video of Furnival 10001-01 starting up with the new settings:
Furnival 10001-01 startup
Disabling IPv6, not waiting for the network, running startup scripts asynchronously but login scripts synchronously
All SLS Office workstations
Disabling IPv6, not waiting for the network, running both startup and login scripts asynchronously
UAT 02 test workstations (mainly N&I Office and test workstations)