How to speed up preparing desktop of a new user in windows 7

2

0

We have a conference room computer that is used my many different people. As such every time someone new logs in it takes as much as 10 minutes from login to responsive desktop. Once the user logs in once it takes no more than 2 minutes to login. I assume the long login is caused by generating the user profile folder. Any thoughts of speeding up the new profile generation other than replace the hard drive with an ssd? Keep in mind that logins must use domain accounts, not local accounts, and we will not know the username beforehand.

tvanover

Posted 2013-05-08T17:51:37.023

Reputation: 1 133

Do you have Roaming Profiles enabled on your domain? You may want to exclude this machine if you do... – Kruug – 2013-05-08T18:03:04.493

No we don't, the profiles are generated from scratch on each machine. – tvanover – 2013-05-08T18:10:16.433

trace the slow creating with xbootmgr/xperf: http://social.technet.microsoft.com/wiki/contents/articles/10128.tools-for-troubleshooting-slow-boots-and-slow-logons-sbsl.aspx

– magicandre1981 – 2013-05-08T18:27:19.503

The machine is not booting slowly once the user account is created, it is only the login process when a domain user loggs in for the first time. – tvanover – 2013-05-09T19:17:40.993

Answers

1

Maybe help a scenario in which profiles are created in advance.

Scenario 1: Replacement of the shell explorer on the script with a call to mstsc.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Shell  REG_SZ <script name>

Preparation:

  1. Make a profile on Terminal Server.
  2. Adjust the station on auto-login

Script body:

  • Call mstsc.
  • Logof part of the script. (This step takes a station in a cycle logoff-logon without giving the user perform malicious actions on the station outside the shell mstsc.)

You can really keep shift pressed, then there will autojoin and you'll be presented with the login windows-domain password.

But if the station is not in the domain, this trick will do nothing.

Scenario Plus:

  • no reboot required
  • profile (with its settings and surrounded by its software)
  • high security (the station may not necessarily be in the domain)

Cons:

  • Writing a script for user logon
  • RDP server infrastructure is needed

Scenario 2: Connect to the resource profile for the conference with the help of a script.

Preparation:

  • Create a profile only for the conference.
  • Create a script which requires login and password.
  • Connect script resources on demand.

    1. Set the profile to work. Save the profile and use it as a template (Before conference).
    2. Save the results of the user (At conference).
    3. Restore the empty user profile for the conference (After conference).

As further sub-options can be offered add and delete user props in the storage details, but it may be a resource conflict.

Scenario Plus:

  • no reboot required
  • connection resources of any user by login and password

Cons:

  • Writing a script for user logon
  • May require the creation or modification of architecture provide the user with resources.

Scenario 3: Creating a user profile in advance using a universal profile.

Preparation:

  1. Create a profile suited to all users.
  2. Add the appropriate permissions to Domain Users to the profile registry keys and profile folder.
  3. Restore a copy of the profile.

Need Rename key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID-Universal>] 

=>

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID-Conference-user-logon>]

Rename record:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist]
\REGISTRY\USER\<SID-Universal> REG_SZ
\REGISTRY\USER\<SID-Conference-user-logon> REG_SZ

=>

\REGISTRY\USER\<SID-Universal>_Class REG_SZ
\REGISTRY\USER\<SID-Conference-user-logon>_Classes REG_SZ

Scenario Plus:

  • Clean profile (if the user has a problem on your profile that here they will not)
  • User security attributes.

Cons:

  • Clean profile (will not be familiar user environment).
  • Requires a reboot.

Scenario 4: Creating a user profile in advance on a copy of the user's profile in advance transferred to the machine.

Preparation:

  1. Login as a user to create profiles.
  2. Copy the user profile to the profile you just created.
  3. Change the permissions and correct entries in the registry

Scenario Plus:

  • Profile user (with its settings, and part of his entourage without Software)
  • User security attributes.

Cons:

  • Profile user (profile problems may be such that no load)
  • requires a reboot

Addition:

User name and the default domain

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
AltDefaultUserName REG_SZ <username>
DefaultUserName REG_SZ <username>

AltDefaultDomainName REG_SZ <domain>
DefaultDomainName REG_SZ <domain>
CachePrimaryDomain REG_SZ <domain>

Hide account who do not want to display, if necessary:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList]
<username1> DWORD 0
<username2> DWORD 0
...
<usernameN> DWORD 0

STTR

Posted 2013-05-08T17:51:37.023

Reputation: 6 180

1I think that most of these solutions are missing the point, I need to speed up the generation of the user profile the first time the user logs in. – tvanover – 2013-05-09T19:20:34.487

@tvanover Software, you can speed up the creation of a profile just change the profile of Default user delete some mechanisms to create a profile. – STTR – 2013-05-10T02:47:28.583