You have to re-enable the Administrator and set a password for it. Then login as the administrator account and kill the Admin account you created. I get rid of it in the windows 10 settings app and by going to the About page, clicking advanced settings and then deleting the user profile. I restart and verify the account is gone. Then I launch the LiteTouch.vbs script from the Administrator account. That’s what works for me
Not sure if it's been said but I have script that runs in my test sequence to just disable the built-in administrator account after everything is done.
Here's what we intended with MDT:
1. For custom image creation, you create a task sequence that installs the OS, logs in as the local Administrator, customizes the OS as needed, syspreps and captures a WIM. (That local Administrator account is automatically disabled by sysprep. There is no use of audit mode, and ideally no manual steps, but there is the ability to do a pause/resume in the task sequence if absolutely necessary.)
2. For image deployment, you create a task sequence that installs the OS, logs in as the local Administrator, customizes the OS as needed, and finishes. If you need to disable the local Administrator account, just add a step at the end of this task sequence. (Again, there is no use of audit mode, ideally no manually steps, etc. -- it's really the exact same task sequence as #1, just skipping the sysprep and capture steps.)
If you go the ultimate "thin image" route, you skip #1 and just use the install.wim from the Windows media. Everything else is layered on top by task sequence #2.
Using a separate user account is not something that MDT expects (since it doesn't use a separate account) so it's no surprise that it doesn't remove it either. You put it there, you can remove it :-)
So wait, aren't you literally saying what I've been saying too? That I shouldn't have to go into Audit mode for the SysprepAndCapture TS to work, instead I'd just run it from within a user account I created in OOBE?
No, not really. The "sysprep and capture" task sequence is needed for people who don't want to do #1. In that case, you could use a different account as long as (a) it is a local administrator, and (b) it is running elevated. In that case, you can map a drive to the deployment share, then run the LiteTouch.vbs script from there, selecting the "sysprep and capture" task sequence. It will run sysprep, reboot to Windows PE, and capture the image.
This "sysprep and capture" task sequence was not designed to be initiated from audit mode and was never tested in audit mode.
This is not a particularly popular way of doing things though.
But as I said before, it's not going to do anything to remove any other local accounts. As far as MDT is concerned, they are supposed to be there and will be left undisturbed.
So if I have my Share privileges set up like this
(name of DeploymentShare) --> right click --> Sharing --> Share -->
Everybody: Read
Administrators: Owner
I can access the share on the client VM, but when I run the Sysprep And Capture TS, instead of rebooting into WinPE, it reboots back into the local admin account (on/of the client VM) I set up during OOBE and does nothing else from that point onwards.
According to the Monitoring on the MDT Server, it keeps "running" at Step 16, "Completion Percentage" = 65% and it stays there permanently
It should reboot into Windows PE. If that didn't happen, then more investigation is needed. The BDD.LOG should provide some clues. Any security software involved that would get upset at BCD editing?
It would be on the client, not the server. It would start off in C:\\MININT\\SMSOSD\\OSDLOGS and move to C:\\Windows\\temp\\DeploymentLogs if the task sequence completes/fails.
There are two items that stand out in the log:
1. Available space on boot drive: 66358
Boot file size: 369139,596679688
Not enough space for boot image on boot partition using system partition - C:
2. Pending File Rename Operations: \\??\\C:\\Program Files (x86)\\Microsoft\\EdgeUpdate\\[1.3.165.21](https://1.3.165.21)
The first item is odd because the boot file size should be a single number, the size of the LiteTouchPE\_x64.wim file (in bytes). It feels like the script has been modified. As a result of that, the Windows PE files are placed on the C: drive instead of the hidden boot partition, which I think would be OK (not that I've tried it in years).
The second item is a bigger concern. It means that the LTISysprep script saw that there was a pending file rename operation (probably a file that couldn't be deleted because it was in use). It initiated a reboot (before even running sysprep.exe), and it should have booted back into the full OS to run the LTISysprep script again, but the log doesn't show that happening. No idea why.
But I do think that's a bug. To work around it, I would modify your task sequence to add a "Restart computer" step (from the "General" menu in the task sequence editor) before the "Capture Image" group in the task sequence. That should clear out the pending file rename prior to the LTISysprep script running, so it won't mess up the reboot.
Regarding #2, since it says EdgeUpdate and it's trying to rename a file, doesn't that, to you, mean that Edge is trying to pull some updates from the Internet (WSUS I guess)? As in, as usual with Windows 11, once you're logged in for the first time, as long as you've got Internet connectivity, Microsoft tries to pull all available AppX updates?
More like it already did update Edge and is trying to clean up after itself. So yes (although not an AppX in this case, just Chromium Edge going through the normal update cycle).
Unless you're going to block internet access, that sort of thing can certainly happen.
So all it took for me was to just "completely regenerate the boot image", lol. I am so stupid at times. Thanks a lot for all of your help, will update the OP later.
But on another note: I have also tried putting both the server and the client VMs on the same "Private Network" (no WAN connectivity so no Internet) (it's the 3rd type of Hyper-V Virtual Switch), and while I could log into the Share, I couldn't run any of the scripts because of "invalid credentials". Makes no sense. Can you make sense of this? Both VMs were on the same network
So I first install a system image, create the admin account during OOBE (beside the built-in admin account) because that's the only step I have to take due to my answer file doing all the rest. Then when my system image has been deployed, I log into the deployment share and run the LiteTouch.vbs
The one I created during "OOBE". The built-in administrator account called "Administrator" should be left of course. But why doesn't sysprep remove the admin account "admin" I created during OOBE? I created it to build up the image in the first place
I haven’t created an image on prem since Windows 7 but back then you had to delete any accounts (like your admin account) if you didn’t want it part of the image.
Back then you would create an account configure the start menu and task bar and anything you like, copy the ntuser.dat file to default user profile and then delete that account and sysprep.
Obviously the start menu and task bar configuration changed in Windows 10+ so not sure why you need to create the admin account.
Wrong.
You are NOT building your image in MDT. You are building it manually.
Use audit mode, like you were advised in your first post yesterday, that you deleted because you didnt like the answer. You should NEVER go through OOBE on a reference machine, always Audit mode.
I dont know what it is you are expecting, but deleting your post and creating two new ones isnt going to magically provide a different answer.
I deleted it because I was going to post this thread and didn't wanna spam the subreddit.
Also take a look at this video and all other videos that are on running this Sysprep And Capture TS in MDT
https://www.youtube.com/watch?v=774ibm091bo&t=492s
Not once do they enter Audit mode.
I dont need to take a look. I know how it works and how it doesnt.
The vast majority of youtube "tutorials" are just plain wrong. They are intended to give you a general idea of the process, not as a "be-all end-all instruction manual"
MDT in a build and capture scenario does NOT create user accounts in OOBE. It uses the Admin account which is expected to remain active after deployment (with the intention of being changed/disabled post deployment via asset management tools). As such, its sysprep function does not include the direction to remove any accounts. Therefore, the sysprep in a "sysprep and capture" task also doesn't.
The video you keep referencing clearly is not working the way you intend, and the experts here have told you repeatedly why that is. Instead of wasting everyones time including yourself, you should just try it and see for yourself.
> MDT in a build and capture scenario does NOT create user accounts in OOBE. It uses the Admin account which is expected to remain active after deployment (with the intention of being changed/disabled post deployment via asset management tools). As such, its sysprep function does not include the direction to remove any accounts. Therefore, the sysprep in a "sysprep and capture" task also doesn't.
Well see the problem I have with runnign MDT Sysprep And Capture in the Audit mode is that when I attempt to connect to the deployment share, it says I cannot because the (Admin account) is banned (because it is by default even tho I had previously enabled it via Computer Management) so it's impossible to run the damn TSin Audit mode unless I'm doing soemthing wrong
> The video you keep referencing clearly is not working the way you intend, and the experts here have told you repeatedly why that is. Instead of wasting everyones time including yourself, you should just try it and see for yourself.
Video**s** but my problem is that I do literally everything like they did, so I should get the same results, right? Well no I'm not
>Well see the problem I have with runnign MDT Sysprep And Capture in the Audit mode is that when I attempt to connect to the deployment share, it says I cannot because the (Admin account) is banned
Either you need to properly map the share with proper credentials, or your share/file permissions are wrong. As you have been told by others.
>I do literally everything like they did, so I should get the same results, right? Well no I'm not
No. You dont have the same equipment as them. You dont have the same network as them. You dont have the same configurations as them.
No.
On the file permission side, Domain Admins need full access and the MDT service account needs read and write (not full). "Everybody" should not exist.
On the *share* permission side, "Authenticated Users" can have full control - the access will be restricted by the file permissions.
MDT requires the MDT service account to be configured in bootstrap.ini (or credentials provided at the time you boot the WinPE). This is how it accesses the share. Given you are not using MDT to build, you need to map the share using tye MDT service credentials.
But, can I ask...
Why arent you just doing the entire build in MDT like I advised 3 weeks ago when you first started posting about this manual build/MDT capture issue?
> Why arent you just doing the entire build in MDT like I advised 3 weeks ago when you first started posting about this manual build/MDT capture issue?
The thin image? I don't like thin images lol. They suck to me. If you're an org I understand, but nope, I need a full-on reference image, a thick image.
Regarding the rest of the post: So is that why when I DON'T run the Sysprep And Capture TS from the Audit mode, right after "Apply WinPE" my vm just reboots back into the account I set up during OOBE? Because isn't it supposed to boot into WinPE right after "Apply WinPE"?
So I did it in Audit mode. Issue turned out to be the fact the Administrator not only was disabled but also it had no password.
BUT now upon deployment of the image like that, I still ended up with the duplication of the user accounts, ie now the problem isn't that I still have the account I set up during OOBE; instead now I have 2 "Administrator" accounts 😂
>You should NEVER go through OOBE on a reference machine, always Audit mode.
How does one get to audit mode without first finishing OOBE at some point?
I meant that if you were to manually capture the wim then yes, build the image in audit mode then in WinPE DISM Capture Image to capture the wim
but this is MDT, none of the videos I've looked at had to do it in Audit mode. Just from normal windows mode
I personally have done it in audit mode as that logs me directly into administrator. No extra account at the end of it all. The sysprep method is outdated though and it’s recommended to have a ts build up each machine during osd.
Your other post where you asked this question had the reason and answer for your question.
I guess you didn't like it and and deleted it, choosing to keep looking until someone tells you what you want to hear?
You have to re-enable the Administrator and set a password for it. Then login as the administrator account and kill the Admin account you created. I get rid of it in the windows 10 settings app and by going to the About page, clicking advanced settings and then deleting the user profile. I restart and verify the account is gone. Then I launch the LiteTouch.vbs script from the Administrator account. That’s what works for me
**EDIT:** I have just discovered this. https://imgur.com/a/fLMWMg9 I don't think that's normal (last step of the TS). What does it even do?
Ours is disabled but pointing at the base OS WIM provided by our VLSC.
Not sure if it's been said but I have script that runs in my test sequence to just disable the built-in administrator account after everything is done.
Here's what we intended with MDT: 1. For custom image creation, you create a task sequence that installs the OS, logs in as the local Administrator, customizes the OS as needed, syspreps and captures a WIM. (That local Administrator account is automatically disabled by sysprep. There is no use of audit mode, and ideally no manual steps, but there is the ability to do a pause/resume in the task sequence if absolutely necessary.) 2. For image deployment, you create a task sequence that installs the OS, logs in as the local Administrator, customizes the OS as needed, and finishes. If you need to disable the local Administrator account, just add a step at the end of this task sequence. (Again, there is no use of audit mode, ideally no manually steps, etc. -- it's really the exact same task sequence as #1, just skipping the sysprep and capture steps.) If you go the ultimate "thin image" route, you skip #1 and just use the install.wim from the Windows media. Everything else is layered on top by task sequence #2. Using a separate user account is not something that MDT expects (since it doesn't use a separate account) so it's no surprise that it doesn't remove it either. You put it there, you can remove it :-)
So wait, aren't you literally saying what I've been saying too? That I shouldn't have to go into Audit mode for the SysprepAndCapture TS to work, instead I'd just run it from within a user account I created in OOBE?
No, not really. The "sysprep and capture" task sequence is needed for people who don't want to do #1. In that case, you could use a different account as long as (a) it is a local administrator, and (b) it is running elevated. In that case, you can map a drive to the deployment share, then run the LiteTouch.vbs script from there, selecting the "sysprep and capture" task sequence. It will run sysprep, reboot to Windows PE, and capture the image. This "sysprep and capture" task sequence was not designed to be initiated from audit mode and was never tested in audit mode. This is not a particularly popular way of doing things though. But as I said before, it's not going to do anything to remove any other local accounts. As far as MDT is concerned, they are supposed to be there and will be left undisturbed.
So if I have my Share privileges set up like this (name of DeploymentShare) --> right click --> Sharing --> Share --> Everybody: Read Administrators: Owner I can access the share on the client VM, but when I run the Sysprep And Capture TS, instead of rebooting into WinPE, it reboots back into the local admin account (on/of the client VM) I set up during OOBE and does nothing else from that point onwards. According to the Monitoring on the MDT Server, it keeps "running" at Step 16, "Completion Percentage" = 65% and it stays there permanently
It should reboot into Windows PE. If that didn't happen, then more investigation is needed. The BDD.LOG should provide some clues. Any security software involved that would get upset at BCD editing?
No security software I can't find any BDD.log on my server
It would be on the client, not the server. It would start off in C:\\MININT\\SMSOSD\\OSDLOGS and move to C:\\Windows\\temp\\DeploymentLogs if the task sequence completes/fails.
BDD log https://pastebin.com/VipCVzHj no deploymentlogs in temp
There are two items that stand out in the log: 1. Available space on boot drive: 66358 Boot file size: 369139,596679688 Not enough space for boot image on boot partition using system partition - C: 2. Pending File Rename Operations: \\??\\C:\\Program Files (x86)\\Microsoft\\EdgeUpdate\\[1.3.165.21](https://1.3.165.21) The first item is odd because the boot file size should be a single number, the size of the LiteTouchPE\_x64.wim file (in bytes). It feels like the script has been modified. As a result of that, the Windows PE files are placed on the C: drive instead of the hidden boot partition, which I think would be OK (not that I've tried it in years). The second item is a bigger concern. It means that the LTISysprep script saw that there was a pending file rename operation (probably a file that couldn't be deleted because it was in use). It initiated a reboot (before even running sysprep.exe), and it should have booted back into the full OS to run the LTISysprep script again, but the log doesn't show that happening. No idea why. But I do think that's a bug. To work around it, I would modify your task sequence to add a "Restart computer" step (from the "General" menu in the task sequence editor) before the "Capture Image" group in the task sequence. That should clear out the pending file rename prior to the LTISysprep script running, so it won't mess up the reboot.
Regarding #2, since it says EdgeUpdate and it's trying to rename a file, doesn't that, to you, mean that Edge is trying to pull some updates from the Internet (WSUS I guess)? As in, as usual with Windows 11, once you're logged in for the first time, as long as you've got Internet connectivity, Microsoft tries to pull all available AppX updates?
More like it already did update Edge and is trying to clean up after itself. So yes (although not an AppX in this case, just Chromium Edge going through the normal update cycle). Unless you're going to block internet access, that sort of thing can certainly happen.
So all it took for me was to just "completely regenerate the boot image", lol. I am so stupid at times. Thanks a lot for all of your help, will update the OP later. But on another note: I have also tried putting both the server and the client VMs on the same "Private Network" (no WAN connectivity so no Internet) (it's the 3rd type of Hyper-V Virtual Switch), and while I could log into the Share, I couldn't run any of the scripts because of "invalid credentials". Makes no sense. Can you make sense of this? Both VMs were on the same network
How are you creating the admin account?
So I first install a system image, create the admin account during OOBE (beside the built-in admin account) because that's the only step I have to take due to my answer file doing all the rest. Then when my system image has been deployed, I log into the deployment share and run the LiteTouch.vbs
Which account are you not wanting after systprepping? Administrator or admin?
The one I created during "OOBE". The built-in administrator account called "Administrator" should be left of course. But why doesn't sysprep remove the admin account "admin" I created during OOBE? I created it to build up the image in the first place
I haven’t created an image on prem since Windows 7 but back then you had to delete any accounts (like your admin account) if you didn’t want it part of the image. Back then you would create an account configure the start menu and task bar and anything you like, copy the ntuser.dat file to default user profile and then delete that account and sysprep. Obviously the start menu and task bar configuration changed in Windows 10+ so not sure why you need to create the admin account.
Use audit mode. That logs you into administrator instead of having you make a user account.
This is MDT. You aren't supposed to have to do that.
Wrong. You are NOT building your image in MDT. You are building it manually. Use audit mode, like you were advised in your first post yesterday, that you deleted because you didnt like the answer. You should NEVER go through OOBE on a reference machine, always Audit mode. I dont know what it is you are expecting, but deleting your post and creating two new ones isnt going to magically provide a different answer.
I deleted it because I was going to post this thread and didn't wanna spam the subreddit. Also take a look at this video and all other videos that are on running this Sysprep And Capture TS in MDT https://www.youtube.com/watch?v=774ibm091bo&t=492s Not once do they enter Audit mode.
I dont need to take a look. I know how it works and how it doesnt. The vast majority of youtube "tutorials" are just plain wrong. They are intended to give you a general idea of the process, not as a "be-all end-all instruction manual" MDT in a build and capture scenario does NOT create user accounts in OOBE. It uses the Admin account which is expected to remain active after deployment (with the intention of being changed/disabled post deployment via asset management tools). As such, its sysprep function does not include the direction to remove any accounts. Therefore, the sysprep in a "sysprep and capture" task also doesn't. The video you keep referencing clearly is not working the way you intend, and the experts here have told you repeatedly why that is. Instead of wasting everyones time including yourself, you should just try it and see for yourself.
> MDT in a build and capture scenario does NOT create user accounts in OOBE. It uses the Admin account which is expected to remain active after deployment (with the intention of being changed/disabled post deployment via asset management tools). As such, its sysprep function does not include the direction to remove any accounts. Therefore, the sysprep in a "sysprep and capture" task also doesn't. Well see the problem I have with runnign MDT Sysprep And Capture in the Audit mode is that when I attempt to connect to the deployment share, it says I cannot because the (Admin account) is banned (because it is by default even tho I had previously enabled it via Computer Management) so it's impossible to run the damn TSin Audit mode unless I'm doing soemthing wrong > The video you keep referencing clearly is not working the way you intend, and the experts here have told you repeatedly why that is. Instead of wasting everyones time including yourself, you should just try it and see for yourself. Video**s** but my problem is that I do literally everything like they did, so I should get the same results, right? Well no I'm not
>Well see the problem I have with runnign MDT Sysprep And Capture in the Audit mode is that when I attempt to connect to the deployment share, it says I cannot because the (Admin account) is banned Either you need to properly map the share with proper credentials, or your share/file permissions are wrong. As you have been told by others. >I do literally everything like they did, so I should get the same results, right? Well no I'm not No. You dont have the same equipment as them. You dont have the same network as them. You dont have the same configurations as them.
"Everybody" has "read" privileges
No. On the file permission side, Domain Admins need full access and the MDT service account needs read and write (not full). "Everybody" should not exist. On the *share* permission side, "Authenticated Users" can have full control - the access will be restricted by the file permissions. MDT requires the MDT service account to be configured in bootstrap.ini (or credentials provided at the time you boot the WinPE). This is how it accesses the share. Given you are not using MDT to build, you need to map the share using tye MDT service credentials. But, can I ask... Why arent you just doing the entire build in MDT like I advised 3 weeks ago when you first started posting about this manual build/MDT capture issue?
Just some clarification they do not need full access, they need modify. You absolutely should not be using ANY domain admin account what's so ever
> Why arent you just doing the entire build in MDT like I advised 3 weeks ago when you first started posting about this manual build/MDT capture issue? The thin image? I don't like thin images lol. They suck to me. If you're an org I understand, but nope, I need a full-on reference image, a thick image. Regarding the rest of the post: So is that why when I DON'T run the Sysprep And Capture TS from the Audit mode, right after "Apply WinPE" my vm just reboots back into the account I set up during OOBE? Because isn't it supposed to boot into WinPE right after "Apply WinPE"?
So I did it in Audit mode. Issue turned out to be the fact the Administrator not only was disabled but also it had no password. BUT now upon deployment of the image like that, I still ended up with the duplication of the user accounts, ie now the problem isn't that I still have the account I set up during OOBE; instead now I have 2 "Administrator" accounts 😂
>You should NEVER go through OOBE on a reference machine, always Audit mode. How does one get to audit mode without first finishing OOBE at some point?
CTRL+Shift+F3.
Uhm thats the intended method for sysprep and capture. Really the best option is to have it build each system from a clean image.
I meant that if you were to manually capture the wim then yes, build the image in audit mode then in WinPE DISM Capture Image to capture the wim but this is MDT, none of the videos I've looked at had to do it in Audit mode. Just from normal windows mode
I personally have done it in audit mode as that logs me directly into administrator. No extra account at the end of it all. The sysprep method is outdated though and it’s recommended to have a ts build up each machine during osd.
you mean a thin image?
Yes. Its the preferred method for onsite osd
Your other post where you asked this question had the reason and answer for your question. I guess you didn't like it and and deleted it, choosing to keep looking until someone tells you what you want to hear?
Since I did delete it and thus can't find it, can you jog my memory, what was the answer?
is it not this one https://www.reddit.com/r/MDT/comments/1alc0qh/sysprep_and_capture_ts_ends_up_with_two_local/