WinPE build with Cloud Build & Windows install examples

[Samuel Melrose]

Hello,

Our company is pretty much all-in on GCP, for everything except our network appliances & end user machines.

We're investigating how we can modernise our imaging technique from building a Windows image in a VM -> sysprep -> clonezilla -> clone disk onto new machines.

Glazier looks like a promising concept, especially combined with splice and fresnel to better handle fully remote workers.

We saw the great blog post with a starting point for getting WinPE running with this repository: https://github.com/discentem/glazier-starter-kit

Our first steps will be to try and combine this with windows-builder for Cloud Build, to see if we can generate the WinPE images with push to build using Cloud Build: has anyone else had any luck with doing this?

After that, I'll be honest, it's going to take some trial & error: the blog post points to a removed script from OSDeploy, but that project looks messy with lots of breaking changes.

The examples in the Glazier repo don't seem to cover everything for a basic install - it has examples for installing apps, but nothing about actually installing the OS or expanding a WIM.

Does anyone have a really basic config for a complete end-to-end install of vanilla Windows 10 and/or how to get to that stage?

Regards,

Samuel Melrose

[ Senior Systems Engineer ]

Tel: 01773 549553

[ A1 Comms Ltd. Contract House, Turnpike Business Park, Alfreton, DE55 7AD ]

 

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender and delete the email. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of A1 Comms Ltd. Please check this email and any attachments for the presence of viruses as we accept no liability for any damage caused by any virus transmitted by this email. Registered Company No. 04455131  VAT No. 282 8135 89

[Samuel Melrose]

To add to this, before we put all the effort into getting the Python version of Glazier configured, I can see there's what appears to be an effort to re-write it into Go.

I can see you are actually using my library, `go-win64api` for some of the BitLocker stuff and I've seen contributions from @Matt LaPlante in the past - no idea you were at Google, thanks!

However, there doesn't appear to be a `package main` entrypoint: is the idea to build your own entrypoint with all the steps you require? And is this a direct replacement for the Python version that'll run inside WinPE?

Please excuse me if these are poor questions - we are a small company and I'm by no means a Windows expert, so it's a bit of a shift to get into these things, but if we can make something useful to serve as a good example, I'd like to publish it to share with the community, to make it accessible to smaller companies with less experience.

[Matt LaPlante]

Hey friend!

The short version is that there is no plan at the moment for a Glazier replacement binary in Go. We've definitely considered it, as we know Python adds a fair amount of complexity to the build environment. Unfortunately our team has a lot of projects already in flight, and we haven't been able to justify committing the time to fully rewriting the Glazier/Autobuild codebase in a new language, at least at this point. We haven't discounted it in the future, but there's nothing formal we can offer in that space.

The glazier/go codebase is at this point a bit of a useful tangent. We're regularly working on new Windows platform tools, some internal, others open source. As Go packages have been needed for these tools, like API wrappers or other common functionality, we've tried to open source them as much as possible. This supports our public Go projects like Cabbie, Splice, etc, and also makes the packages available to other Windows developers who may find them useful around the community. It also leaves the door open for us to do more Go-based work in Glazier tooling in the future, but as I was saying, the binary is not something we're working on in the near term. 

As far as the Glazier configuration question, your observation regarding trial and error is probably going to be correct. The codebase is pretty flexible and capable once configured, but it's also one of the more open-ended tools we've published. We continue to use it in our own environment, but it's heavily customized, so we're somewhat challenged in giving turnkey examples that would work for your own situation. 

Lastly, while product support is formally only best effort for these tools, if you run into bugs or would like to make contributions, please do let us know via GitHub.

--
You received this message because you are subscribed to the Google Groups "glazier-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to glazier-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/glazier-discuss/849ae459-83bc-48f6-8f50-b34efb85ed5bn%40googlegroups.com.

[Samuel Melrose]

Thanks for the response & your clarifications Matt, really appreciate it :).

Trial and error ended up being the way, but that really made us appreciate the ability to change the config in the Glazier repo & re-run the tool, even within the same WinPE session while debugging.

We definitely aren't using the tool to its full potential, but we ended up mixing it with OSDCloud to minimally configure a blank OS directly from Microsoft Update & install our internal management tool.

The internal management tool handles everything else from there after manual confirmation using existing tooling, so it's worked really well for us & it's super easy to jump between Windows Feature Updates as they are released.

I've published our progress to our fork of the glazier-starter-kit repo: https://github.com/a1comms/glazier-starter-kit

We've still got to update it with our tooling for the WinPE image creation for it to be a real end-to-end example, but hopefully it helps someone else on their journey.

I've obfuscated some of the unattend.xml values in the repo, but if you happen to find our production unattend.xml (we aren't really trying to hide it), we are aware the passwords are exposed, but they are automatically rotated once the management agent is installed, so we aren't worried about them being public.

Regards,

Samuel Melrose

[ Senior Systems Engineer ]

Tel: +44 (0) 1332 922429

[ A1 Comms Ltd. Contract House, Turnpike Business Park, Alfreton, DE55 7AD ]

 

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender and delete the email. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of A1 Comms Ltd. Please check this email and any attachments for the presence of viruses as we accept no liability for any damage caused by any virus transmitted by this email. Registered Company No. 04455131  VAT No. 282 8135 89