Startup Delayer is easy to install and setups quickly. After installation has completed, Startup Delayer will open, showing you a list of Programs that start when you logon. The first thing you want to do is activate it by clicking on the red icon on the toolbar labeled SD and selecting Graphical Version. When in Graphical Version mode, Startup Delayer will display showing the status of each Program as it is starting during the logon process.
Next, double click on each Program and set the delay to the time you want to specify then click save. I like to start with three seconds for the first one and increment by three to five seconds for each Program until I'm finished.
Once you have made you settings, you are finished and ready for a faster logon time. Inthe future, as you install programs, open up Startup Delayer and and set the delay time for the new program. Next time you startup you will see Startup Delayer panel, showing you the status of each programs it is starting. Over time you can make adjustments to further decrease logon times. Now you may think by setting the order of how programs load, may seem like it will increase the time to logon.
But by setting the order, your Computer will not need to multi task and provide additional resources to handle multiple programs loading at once. Loading programs one by one, will allow the Computer to respond quicker and eliminate the switching back and forth to allocate Processor time and valuable resources.
This benefit will be greatly notice for Programs that require significant resources to start up. Filed under Windows Tips by Mike Boyds. Juat a note. Ivanti User Workspace Manager and LiquidWare Labs ProfileDisk also have this capability, but currently the most flexible and feature-rich way to do the VHD mount is using FSLogix Profile Containers, which allows multi-session capability and can also replicate the profile stores and use a cached local copy by leveraging a feature called CloudCache.
In my opinion, if you want to get the most efficient handling of a profile from a logon perspective but still have smooth roaming and centralized management, FSLogix Profile Containers is the way to go currently. It will, in some cases, shave literally minutes from the logon time.
The second biggest way to shave logon times particularly on Windows 10 is by creating a custom default user profile, instead of using the one provided with the OS. It is important, though, to stress that most of the gain is made by strimming the profile down as specified in the last section of the article.
You can also go a bit further than just the permissions changes and file deletions specified in the article if you want to make the profile even slicker You can, should you wish, use the custom default profile to apply any global settings you would normally deploy via user GPOs think desktop background, browser home page, etc. However, if you wish to enforce these as policies, then you may need to use the GPOs to do so. If there are any global settings that you can enforce on a machine rather than a user level sometimes settings have a corresponding value in HKLM which will be used if the HKCU value is not present — proxy server is a good example of this then you can use these settings enforced by Group Policy Preferences to further reduce your requirement for GPOs.
I have also seen mainly in environments where logon time is absolutely critical people loading the custom default user profile with the actual Registry values that apply to particular global GPOs, ensuring that the GPO settings are preloaded, rather than having to be processed.
Active Setup is a feature that will affect you if you are using full desktops, not published applications. It is, bluntly, a mechanism for executing commands once per user early during logon. Active Setup is used by some operating system components like Internet Explorer to set up an initial configuration for new users logging on for the first time. It is a way of hard-coding user-specific data.
Active Setup runs before the desktop appears. Commands started by Active Setup run synchronously, blocking the logon while they are executing.
You can tell Active Setup is running when you see images like that shown below. Active Setup employs neither a timeout nor any other mechanism to determine if a StubPath process it started is still alive, so if it hangs, the entire logon will stop.
Any found will be executed at this stage of the logon process. Now, there are some StubPath entries that you may need, such as. Net components, but some of them are literally absolutely irrelevant to the modern world and I fail to understand why Microsoft have not removed them from Windows.
Windows Mail is the one that springs to mind instantly. Also, other installed software such as Google Chrome may well insert its own StubPath entries here. An example of a StubPath entry is shown here. When dealing with Active Setup entries, my approach is usually very aggressive — I delete as many of them as possible. However, it is important to assess whether there is any impact on any of your applications by removing them. Ideally, if there is anything deployed by the StubPath entry that is required for application performance, then it would be prudent to capture it and deploy the settings in a different way — maybe even wrap the settings up into the default profile?
But it definitely has a big impact on reducing logon times for desktop sessions if you remove as many of the Active Setup entries as you can. Desktop is the main one — having hundreds of files on the desktop has a detrimental effect on logon times. Recent Items is another, but this cannot be redirected through Group Policy any more — it can only be configured by tools such as Ivanti UWM, or through direct Registry manipulation.
From the standard GPO redirections, only Desktop and to a lesser extent Start Menu have a detrimental effect on logon performance. Particularly for Windows 10 XenDesktop, this will make a big difference to logon times, as this version of Windows presents the logon interface long before background processing has finished.
It is important to understand when your peak logon times are in order to ensure that enough machines are pre-booted ahead of the demand — at least ten minutes prior to logon will ensure that all processing is cleanly finished. If you power up enough machines to meet demand at least ten minutes ahead of time, you will see a much better logon performance, most markedly if using Windows Namely, that when you logged on to a Windows VDI session for the second time, the logon was fully two seconds faster than the first one after booting up.
But I tested this something like forty times off the belt, and it showed the same every time — two seconds faster for a second logon after bootup, rather than the first. It was nothing to do with the contention issues after boot either — I let the machine sit for an entire hour before logging on after it booted, and still the result was the same, a full two seconds faster second time around.
It can be done. Create a user called autologon or similar. I used to create a local account and deploy it via Group Policy Preferences so it exists on every machine, but Microsoft removed this functionality from GPP, so you will have to do it another way. Putting it in the base image is easiest.
Configure a Startup Script for the machine that sets the Registry values that will enable automatic logon. The following would suffice. Now, set up a Scheduled Task and set it to run in the context of the autologon user. Set it to be triggered when the autologon user logs on, and call the script you just wrote and stored on the local machine.
Also you need to make sure the autologon user has rights to edit the Winlogon Registry key. You can set this manually, or use a Group Policy Object to do it.
Now, when the machine boots up, the Startup Script will set the autologon. The user will log on, the logon will trigger the Scheduled Task, which will remove the password disabling the autologon and then log the user out.
Hey presto — every first logon will now actually be a second logon, shaving another couple of seconds off your logon times. If you are then it makes sense to disable the reboot at logoff and implement this. If not, then it would be more prudent to disregard it.
Of course, the upshot of finding that George had done the auto-logon and blogged it was that I found another cool tip in his article which brought my logon times down even further. It involves preloading a bunch of applications at startup, and then killing them off afterwards. Run this as a Startup Script or a Scheduled Task triggered at startup, and you will have even more benefits. Specific to Windows 10, this tip will again reduce contention at boot and therefore reduce logon times.
Windows 10 appears to create firewall rules for each AppX application on a per-user basis. These rules are not removed when a user profile is deleted, and often contain large amounts of duplicates. At boot, Windows iterates through the firewall rules and can take a long time to parse them if there are a large number.
One example I saw of this had over twenty thousand entries on an open-access computer. In order to get the best possible logon times, it makes sense to remove the rules. Now, there is a school of thought that suggests disabling unneeded Citrix virtual channels will save you logon and reconnect time as well. Each Citrix virtual channel handles something different, and some of them may not be in use in your environment.
You can disable specific virtual channels by editing the following Registry value on the connecting clients not the actual target VDA, the client with the Receiver software on it. This article should provide a decent guide as to the functionality of each entry or file. If you disable the maximum amount of entries in here, you can take about three seconds away from the Citrix logon or reconnect time. You can also disable virtual channels via Citrix policies , although I have not tested whether these will bring a similar logon gain.
Another huge drag not just on logon performance but on in-session performance is the use of antivirus and other intrusive security software. In an ideal world, we would get rid of reactive antivirus and replace it with something different, but regulatory requirements such as Cyber Essentials often make this a difficult sell to enterprises.
Apply all the required exclusions. If possible, disable realtime monitoring and move to scheduled scans, preferably when the system is not under load. Perform the same recommended actions for all security software. Anything that hooks into processes should be investigated carefully to see if there is any impact on user logon times.
The whole debate about reactive antivirus and its place in a modern infrastructure is one for a different article which I will hopefully put together soon, but I prefer a robust approach based around newer Windows 10 security features like AppGuard and DeviceGuard, combined with application whitelisting technologies.
There are many, many Scheduled Tasks configured on Windows these days and some of them run at user logon. You may need to verify some of them, but I will warrant there are a good few that could do with being removed.
Grab the SysInternals tool AutoRuns and run it against your targets. Use the Citrix Optimizer! Net assemblies, disabling unneeded services, disabling NTFS access timestamps, etc. Running this on a golden or reference image will make a big difference not just to logons but all round performance for the user session.
Another excellent tool, this one from Login Consultants, this is for image optimization but not just on the OS level, it also works on aspects of common installed software as well, and even does optimization of components like antivirus. Defragmentation — is this still a thing? You stated to keep the Policies together. But there are gotchas on this. If your AD layout is separated on Users and Computers. If you can get away without any filtering, then even better.
The best filtering is by OU, if it can be done. Super Article! Lots of great details and tips for speeding up logons. Computer and Users settings. I have 2 little dinky GPOs I should merge into the one policy above.
That is what your saying is optimal correct? I believe that is what your saying. Our issue is mostly not around logon times of Windows as we have optimized it. Analysis of logon times - how to speed it up Moved a Pupil test logon "" to the same OU.
After reading here: Default mandatory profile is slow to logon - is this normal? This is from our standard build windows 7 computers: Windows Registry Editor Version 5. If you want a non-reg hack way of disabling Windows Mail, it can be achieved through group policy CPU Config - Admin Templates - Windows Components - Windows Mail - Turn off windows mail application - enabled Otherwise it would be worth looking at the default profile on your machine and ensuring that it is as clean as possible.
From my own experience, I know that Browser Customization tends to take a fair while to run through Thanks to simpsonj from: gshaw 29th June Thanks Anyone else know which of the above can be deleted to speed up logon times and which might be essential to proper operation? Originally Posted by simpsonj. Last edited 29th June at PM.
Originally Posted by kennysarmy.
0コメント