@taspharel @Avaryan

Thanks guys, collectively this helped me achieve what I was trying to accomplish.

Appreciate your assistance

Update to thread: These sed scripts can/could be called from a fog postinit script to ‘patch’ the fog scripts on each FOS boot. This way you would never need to unpack the inits and would fully support updated scripts in the future.

I did write a tutorial on the postinit scripts here: https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins

@datastream I would suggest you ask on the ClamWin forums here: http://forums.clamwin.com/

@sudburr hey thank you for this, you are really more advanced with the dpinst usage.
Appreciate your post a lot 🙂

@george1421 So I just logged in and opened word. After it opens it has the window that says first things first and you choose how it will install updates. You have to be an admin to set that. After that the window pops that asks “How do you want to activate your software?”

After you click through those it is ready to go. Is there a way to automate that so it is done already? It’s not a big deal. I can login to each machine and click through those, but if it can be done I would set it up.

@quazz
No I did not, I just thought of that yesterday and was able to get it working fine now. I just now have to try out making the image with removing Edge and the Windows 10 Apps with PS Scripts.

@chris6862 FWIW: Between image captures I’ve used the FOG post install scripts to “patch” the target image as FOG deploys it to the target machine.

In our process we rebuild our reference image once a quarter. We have to go through and validate that the reference image works on all 12 models in our fleet before we can release it in fog for deployment. If we discover a gotcha after its been approved and released (as in needing to add something to the unattend.xml file or setupcomplete.cmd) We will have a post install script run to slide in the correction once imaging is done, and before the system reboots into windows setup. I’m not saying that this process will solve your issue here, but it IS a workable option if you need it.

@x23piracy Well for windows 7 it wasn’t needed to sysprep to activate windows 7 licence and since we don’t have a microsoft domain it wasn’t necessary to use sysprep anyway… i think… 😄 It was working at least… xD

@aksl Are keen to get your hands dirty and dive into “compiling and debugging iPXE”?? If yes is your answer, there is a way I could lead you.

Sorry for the late response. I have not solved the issue but I also need to get some other items finished. I believe the root cause in this situation is not FOG but SCCM getting in the way. I might not have time to circle back to this until next month. I am leaving for our Florida office in a few days to help with things down there and attending Microsoft Ignite that last week of the month.

Hi,
Thank for answers …

@george1421 :
I’m not sure if i really understood your things …

You said :
you may need to use persistent groups to set some default actions
Can you write an example ?

You will have the most flexibility if you use the post install scripts to connect to AD
I use post install scripts to connect my AD with the desktop computer. But, for theses laptops, i don’t need to connect to AD …

I think, i’m not really need to alter the unattend.xml because i use a specific unattend file for theses laptops.

You can only install “things” that windows will find during installation : yes, i understood this part 🙂

I use my specific unattend file to create my user Utilisateur. But i can’t personnalize this user with unattend …

@Seb-B : i will try your way 🙂

I will be back !

@kevinaguiar said in ComputerName in OOBE Windows 10 Pro Sysprep Machine:

Returning to FOG, I thought of solutions like CloneDeploy (http://clonedeploy.org/), where it edits the unattend file, editing the <ComputerName> </ ComputerName> tag and putting the hostname that was defined in Web interface. Is it possible to do something similar in FOG?

Yes you can do this in a fog post install script. That is how I do it in my company. I don’t use fog to rename the computers, because our computer names are calculated based on where the image is deploying, what image type is used and then the asset tag is appended to the end of the that other prefix info. So it is possible to do.

If you have found a solution then great, if not let me know and I will show you how it can be done.

@lebrun78 Thanks for letting us know. Good you got this solved! Marked as solved.

@espynn In such case, I’d recommend creating a fresh & clean image to try out next.

@george1421 We were successful yesterday when we used the image we created on our Stem machine. We were able to do perhaps 4 PC and all worked perfect. To say we were excited at the possibility to knock these out so fast is a gross understatement.

Today using the same image we have the boot issue. Now to be fair perhaps it is a driver issue. I am not sure if we have all possible drivers loaded.

I am 95% sure we tried a capture from the reference image (swap the hard drive with a blank one) and deploy back to the same hardware and it didn’t work. But I might be wrong since we tried maybe 10 different things today on top of trying to manage our 11 store 600 PC environment. It can get a bit confusing at times.

I will try that for sure next as well as making sure we have the right driver packs.

Auto logon values are stored in the registry. Run the following PowerShell script to determine your current AutoLogon settings.

$path = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' $AutoAdminLogon = (Get-ItemProperty -Path $path).AutoAdminLogon $DefaultUserName = (Get-ItemProperty -Path $path).DefaultUserName $DefaultPassword = (Get-ItemProperty -Path $path).DefaultPassword $AutoLogonCount = (Get-ItemProperty -Path $path).AutoLogonCount Write-Host "Current AutoLogon Settings:" -ForegroundColor Yellow Write-Host "AutoAdminLogon: $AutoAdminLogon" Write-Host "DefaultUserName: $DefaultUserName" Write-Host "DefaultPassword: $DefaultPassword" Write-Host "AutoLogonCount: $AutoLogonCount"

Output from my Windows 10 1607 laptop:

Current AutoLogon Settings: AutoAdminLogon: 0 DefaultUserName: Administrator DefaultPassword: AutoLogonCount:

AutoAdminLogon has two states. If it’s 0, then it’s disabled. If it’s 1, then it’s turned on.
AutoLogonCount indicates the remaining number of automatic logons. This number decreases by one every time the computer restarts, until it reaches 0. When it reaches 0, it changes AutoAdminLogon to 0 and clears the DefaultPassword. Setting this to any number below 0 will effectively set your computer to automatically logon forever.

Try using defprof. It can transfer a lot of the settings to default profile.

https://www.forensit.com/support-downloads.html

@joe-gill well done.

@avaryan FWIW, you can start with a online generator to build your basic win10 unattend.xml file: http://windowsafg.no-ip.org/win10x86_x64.html To that we add in the section to load the drivers from a known location. We have to do this because some driver are needed for the OOBE process (we use a single image developed on a vm for all computers in our fleet) to run successfully. Then in the setup complete we use dism to inject any drivers missed during the initial OOBE process (mainly because some hardware is hidden behind other devices that needs it driver loaded first).

In our deployment process we use the unattend.xml file to connect to AD and not the fog client. We calculate the target OU based on several factors that is calculated at deployment time. This dynamic OU selection isn’t possible using the standard FOG environment. So we use a post install script in fog to update the system’s host name, location, timezone, OU location and a few other things that escapes me right now.

Since we use MDT to build our reference image you don’t need to mess with audit mode to default user profiles that is managed by the mdt process.

@john-sartoris Hmm, seems they’ve switched back and forth between the two on several occassions, bah.