We saw in the previous post, how OSDCloudGUI looks like and which options we can have for starting a bare metal installation.

In most of my cases, I try to minimize the end user interaction and try to automatize the process as much I can. Just to use the ZTI (zero touch installation) principle.

Zero Touch Installation

Zero Touch Installation (ZTI) – is a fully automated deployment solution that require no user interaction. For me the most important thing to automatize all of the possible IT processes, is the consistency.

Any time you trade off selecting (whether parameter or menu), and have people involved, mistakes can happen. Running OSDCloud ZTI will ensure that every deployment is configured identically (assuming you like the defaults, or you remembered to put in the proper parameters).

In the next chapters I will show you the different ways to start these kinds of automations.

ZTI

Easiest way to start a kind of zero touch deployment to use this line in WinPE:

Start-OSDCloud -ZTI

ATTENTION: OS disk will be cleaned automatically without confirmation!

Start-OSDCloud has default values. These are using like for a ZTI:

Start-OSDCloud -OSVersion 'Windows 10' -OSBuild 20H2 -OSEdition Enterprise -OSLanguage en-us -OSLicense Volume

WinPE / Startnet.cmd

During WinPE creation process on our reference machine, we are able to define the first command which we want to execute after the machine boots into WinPE:

Edit-OSDCloudWinPE -StartOSDCloud "-OSVersion 'Windows 11' -OSBuild 22H2 -OSEdition Pro -OSLanguage de-de -OSLicense Retail"

This command modifies Startnet.cmd which starts at the beginning of the process:

You can modify this batch file directly too, with the following commands:

$Startnet = @'
start /wait PowerShell -NoL -C Install-Module OSD -Force -Verbose
start /wait PowerShell -NoL -C Start-OSDCloud -OSVersion 'Windows 11' -OSBuild 22H2 -OSEdition Pro -OSLanguage de-de -OSLicense Retail
'@
Edit-OSDCloudWinPE -Startnet $Startnet

These changes are still a bit static: if you need some change in these commands, you have to build a new bootable image and deliver to the customer.
Let’s see how we can move either in direction dynamic script management.

Gist

You can create a public (visible to everyone) or a secret (hidden by search engines, but visible to anyone having the URL) gist on GitHub:

Then I need to get the raw URL using the Raw button. This gist link has the following logic: https://gist.github.com/[gist_user]/[gist_id]/raw/[file_name]

I recommend to remove the “file_name” part from the URL. Because after every gist change, this name (id) will be changed. We can focus only for the “gist_id“. So, we are a bit version independent.

https://gist.githubusercontent.com/AkosBakos/d3aa730ede07fa083c6a023dbba8ea9e/raw/7fbb16ce2a19742efdd4eeb02d131c38e48d1859/StartOSD.ps1 --> https://gist.githubusercontent.com/AkosBakos/d3aa730ede07fa083c6a023dbba8ea9e/raw/StartOSD.ps1

Optionally, we can create a CNAME in our domain provider to use more shiny and shorten URLs, like here https://zti.osdcloud.ch

Now we can change the WinPE config again:

Edit-OSDCloudWinPE -WorkspacePath $WorkingDir -WebPSScript https://zti.osdcloud.ch

Lean back and watch the magic of ZTI:

These scripts can be stored in your GitHub repository, Dropbox or whatever online storage you have with access directly to your file.

GitHub / Start-OSDPad

Start-OSDPad command will allow you to use OSDPad to deploy machines using scripts on GitHub.

Edit-OSDCloudWinPE -StartOSDPad "-RepoOwner AkosBakos -RepoName OSDCloud -RepoFolder ScriptPad -BrandingTitle 'Akos OSD Cloud Deployment' -Hide Script"

You can put all of the OSDCloud magic here. One of the best advantages in my point of view, when you want to change or edit these scripts, you can do it instantly and smooth. For instance, when a customer has any issue, you can quickly check the source and optionally make a change online.

You can have two options to maintain and store these scripts:

• Public repository is accessible to everyone on the Internet.
• Private repository is only accessible to you, people you explicitly share access with, and, for organization repositories, certain organization members.

In my opinion, these scripts are not storing any business related and sensitive data. But I would recommend anyway to have a playground in a public repo. The logic for production, you should store in a private repo.

Public

Working with public repo, you can check my fellow Mattias blog post here.

The following GitHub API call will be used for the function Start-OSDPad: “https://api.github.com/repos/$RepoOwner/$RepoName/contents/$RepoFolder”

RepoOwner: GitHub username

RepoName: GitHub repository name

RepoFolder: GitHub folder where the scripts are stored

So, we need these parameters, like in my example:

Start-OSDPad -RepoOwner AkosBakos -RepoName OSDCloud -RepoFolder ScriptPad -BrandingTitle 'Akos OSD Cloud Deployment' -Hide Script

Hint: with -Hide parameter, you can hide the script content after starting OSDPad. Without this parameter you can see the script logic AND you are able to change it on the fly. It helped me more times, that before script start, I could have some command changes.

Private

If you are using private repo, you need first an OAuth token to have access to them. You can create this token at https://github.com/settings/tokens.

Think about the expiration time of this token!

The token needs to have the following GitHub repo permissions:

When you have made this setup, you can use Start-OSDPad like this:

Start-OSDPad -RepoOwner AkosBakos -RepoName OSDCloud -RepoFolder ScriptPad -BrandingTitle 'Akos OSDCloud Deployment' -OAuth XXXXXXXXXXXXXXXXXXXXXXXXX

Summary

My OSDCloud customer setup looks in most of the cases like that:

• The startup command is stored in a secret gist, where an alias URL is always defined.
• Most of the customers have more OSDCloud profiles. These scripts are stored in a GitHub folder which is in a private GitHub repository.

I hope, I could show some possibilities how and where you can manage your startup scripts and profiles. At the end of the day, you will have to choose a starting and storing method. Then you are ready to go for a bare metal OSD.

But what comes next, like what happens in the out-of-box phase? Stay tuned and check the next OSDCloud blog post. 😉

Happy #OSDClouding!