0

I need to amend the default user account during deployment of Windows 7. Having read the following MS article: http://support.microsoft.com/kb/973289 I have a few questions. The article suggests that the amendments must be made under the built in local administrator account. Does this have to be the built in Admin account? or can the changes be made under the context of another local account within the local administrators group. The customer does not wish to enable the the built in admin account. Is the profile copied from the account that is currently logged in when the specialise path is initiated?

The article also says to remove all existing local accounts. I assume this is because the amendments to the default profile will not apply to these accounts. Basically, the image has some existing local profiles that must remain. The default settings do not need to be applied to these accounts.

I would test this out but I currently do not have access to my test environment unfortunately.

Any guidance is greatly appreciated.

Thanks in advance.

5
  • If the support article says the default administrator account needs to be used then it needs to be used. You only need to use the default administrator account to CREATE the image you can set the default profile to anything you want.
    – Ramhound
    Jan 9, 2013 at 18:34
  • I don't quite understand what you mean when you say that the default administrator account must be used to CREATE the image. Please clarify. The support article also says the following; 'remove all added user accounts except for the one Administrator-level user account that you used to log on to Windows.'You cannot delete the built-in administrator account so I was curious as to why it said this.
    – JHamill
    Jan 9, 2013 at 19:16
  • @Ramhound - you'll also see on this article technet.microsoft.com/en-us/library/cc748953(v=ws.10).aspx that it says that an account that can be customised can be used. Not specifically the built-in admin account.
    – JHamill
    Jan 9, 2013 at 19:40
  • I just built a share for a new client, and what I got away with was disabling the Admin account at the VERY end of the task sequence. Worked like a charm.
    – MDT Guy
    Feb 13, 2013 at 15:50
  • Try this (posted by me elsewhere on superuser.com)... superuser.com/a/769138/333580 Good for renaming any user by copying the profile and creating a new Default user with those settings. You can then easily create new user(s) with your preferred settings.
    – pjbeee
    Jun 16, 2014 at 13:23

2 Answers 2

4

If you're trying to build a customized default profile, but you don't want the admin account enabled, use it, run sysprep and disable the admin account from your unattended answer file. Make sure you're using WAIK at the very minimum, It's highly recommended using WAIK in conjunction with MDT.

http://www.microsoft.com/deployment

In win7 you use the local admin account to build the default profile, but much of what used to need to be done by hand in the xp days can mostly be done with your unattend.xml answer file.

You will need to use the copyprofile=true setting in the specialize pass in the unattend.xml file when you run sysprep or it will not work.

WSIM Screenshot The setting in WSIM

       <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
        <RegisteredOrganization>Spud-Co Labs</RegisteredOrganization>
        <RegisteredOwner>Administrator</RegisteredOwner>
        <DoNotCleanTaskBar>true</DoNotCleanTaskBar>
        <CopyProfile>true</CopyProfile>
       </component>

Sample For a 32bit Win7 Unattend.xml file

Although you may get away with having other profiles created already in the reference image, just understand that it's not recommended, as sometimes, sysprep may generalize settings from those profiles, not the admin, that's why its advised to not have them.

To play it safe, configure your reference account with the admin account, and run sysprep from there.

A clean, complete and concise guide to running sysprep can be found here: http://theitbros.com/sysprep-a-windows-7-machine-start-to-finish-v2/

I'm not 100% sure that sysprep redisables this account for you, and you may have little luck turning back off from the answer file. Use MDT to deploy with a task sequence, this will allow you to disable the account at the very end of the deployment.

Try this in the Windows Deployment, Run Synchronous Section, it should disable the account after you run sysprep.

            <RunSynchronousCommand wcm:action="add">
                <Description>EnableAdmin</Description>
                <Order>1</Order>
                <Path>cmd /c net user Administrator /active:no</Path>
            </RunSynchronousCommand>

To make life easier on yourself, test all this in some kind of VM. I recommend virtual box, but any VM should work.Take a snapshot before you run sysprep, and that way you can test the answerfile and revert easily and save a lot of time.

UPDATE: Recently I had some luck using MDT and the Built in Admin, but creating a second account, making it admin, then disabling the admin at the very end of the task sequence using MDT. I don't think this can be done using the stand alone xml file, to get away with this you most likley need to use a MDT task sequence.

4
  • Thank you for your response. I'm actually using LANDesk Provisioning to deploy the OS and apply the Unattend file. So just to confirm, when CopyProfile is set to True it will copy the profile of the built-in admin account? I ask this because I wanted to use another account for AutoLogon within my Unattend file. Another question is that within my Unattend file I do not make use of the generalise pass. Instead I use the specialise pass which does contain the Microsoft-Windows-Shell-Setup component and the CopyProfile value. Will this have any bearing on the outcome at all? Thanks again.
    – JHamill
    Jan 9, 2013 at 14:17
  • As a further point, I fully intend to replicate this within my VM environment as soon as I have access. :)
    – JHamill
    Jan 9, 2013 at 14:21
  • You may be able to use another account for the autologin, but it would most likley require creating that account after the image is captures by using syncronus commands also in the answer file. I think you may actually be correct, the copy profile setting may need to be in the specialize pass, not generalize, check and see.
    – MDT Guy
    Jan 9, 2013 at 18:12
  • Excellent, thank you for your help on this. From the articles/blogs I have read it appears that it must be in the Specialise path. I'll test this and post back with my findings. Thanks again.
    – JHamill
    Jan 9, 2013 at 19:20
2
+100

The proper method to configure the default user profile is before deployment, by using the built in administrator account and the ‘CopyProfile’ setting in the unattend.xml file as noted in the ‘Customize the default local user profile when preparing an image of Windows’ (which you linked in your original post). As MDT Guy pointed out in his post, and as mentioned in the above article, “If there are multiple user profiles, Windows sysprep may select an unexpected profile to copy to the default user profile”. Therefore, there should be no other profiles present.

This article also states that the built-in administrator is deleted (and re-created) during a clean installation or during the sysprep process, so there should be no need to disable the account in the answer file. The newly created administrator account will be disabled automatically and will also use the default user profile, so the default user profile settings will be carried over.

This also means that the default administrator account is not the default user profile, so changes made to this account will not propagate to the default user account without using the CopyProfile setting in the answer file.

If this is a system that cannot be re-imaged (you mention other profiles that must remain), there may be some other things that you can do to achieve your required changes, such as Group Policy settings. This article from the Springboard Series Blog may be of some help.

You may also find additional help for Group Policy settings on the Manage and Operate Windows 7 page of the Springboard Series on TechNet.

Hope this helps

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .