These guides are intended for advanced IT administrators deploying CloudReady in an environment with a pre-existing mass deployment infrastructure. These guides also assume that the reader has previous experience with configuring and using the given the specific mass deployment tool that the guide is associated with.
Note: For organizations deploying CloudReady to fewer than 100 machines, we recommend using our automated USB maker tool, as it typically results in faster deployment times.
These instructions assume that you already have a fully functional Microsoft Windows Deployment Services (WDS) infrastructure at your site.
Be aware that as of August 2019, after the release of CloudReady version 76.4, CloudReady will only offered for 64-bit capable devices. For more detailed explanation, see the following thread here.
Before getting started, let’s establish a formal set of requirements that you’ll need for the deployment:
- CloudReady_WDS_Tools.zip, a collection of scripts and tooling that are required to conduct the imaging process within the WinPE environment.
- A custom CloudReady image for your organization, designed for WDS deployment. The standard installation files available on my.neverware.com will NOT function for mass deployment. Please contact support to have one created for you at no charge. The process will generally take 1-3 business days.
- Access and approx. 40 GB of storage space to create a network share for hosting the imaging scripts, CloudReady image file and associated tooling.
- A network account with the proper read access to the share.
01. Customize settings for your network
1. Network share creation: Using an account with proper administrative access, create a shared folder on your network and extract the contents of CloudReady_WDS_Tools.zip into it.
Note: In our example screenshot below, we’ll use our local NFS server and create a folder named cloudready.
2. Setup share and NTFS permissions: Assign the proper read permissions on both the share permissions and NTFS security to the target folder as shown below.
Note: In our example below, we created a user called deploycloudready on our lab domain, and assigned appropriate permissions to this account.
3. Download: From the downloads section of your my.neverware.com account, download the appropriate image for your WDS deployment. 64-bit deployable images are available in both UEFI and Legacy BIOS boot variants.
4. Unzip: Once the proper deployable image is available and downloaded; unzip the large (more than 10GB) .bin file into the same shared network folder that was created in Step 1.
5. Browse to our share folder and edit the startnet.cmd file and replace the following placeholders:
USERNAME: The username of a domain user that has read permissions to the network share containing the CloudReady files.
- Following the guide's example, the username would be deploycloudready
PASSWORD: The password for the domain user that has read permissions to the network share containing the CloudReady files.
- Continuing the guide's example, this would be the password created for the deploycloudready account.
DOMAINNAME: Your Windows domain name.
- In our example deployment, the domain name used in our lab is CLOUDSTEADY
\\SERVERNAME\SHARENAME: The network path of the share containing the CloudReady files.
- Following the examples used in this document, the path would be: \\nfsserver\deployment_share\cloudready
FILENAME.BIN: The name of the large .bin file.
- In our example, this would be cloudready_deployable_64bit_uefi.bin
6. Save the startnet.cmd file after making these modifications.
02. Edit the Boot Image
Following the typical format of creating a customized WDS deployment image, in this step we’ll edit our wim file to include our new startnet.cmd file created in the previous step.
1. Connect directly to the file share server hosting the CloudReady share using RDP, or another access method, in order to establish a direct session.
Note: The following commands cannot be executed on a remote network share (unless using a remote command prompt, like psexec).
2. Launch an elevated command prompt running as administrator.
3. From within the command prompt, change directory to the folder containing the CloudReady files. (This step is for simplicity so we don’t have to type the full path).
- Continuing our example, the commands entered would be:
4. Mounting the .wim file: Within the command prompt, execute the following command, substituting the actual local share path of the folder containing the CloudReady files and the target working directory (tmp) using the following structure:imagex /mountrw [your path to cloudready.wim file] 1 [your path to tmp folder]
Explanation: This command will use the imagex utility to extract, mount and modify the contents of the cloudready.wim file, included in our CloudReady tools package, in order to include our custom startnet.cmd.
- In our example, the command would look like this:
imagex /mountrw z:\deployment_share\cloudready\cloudready.wim 1 z:\deployment_share\cloudready\tmp
5. The contents of the cloudready.wim file will now be mounted in the "tmp" subfolder we defined in the previous step.
- In our example, the \tmp folder should look like this:
6. Using windows file explorer, let’s go back and copy the startnet.cmd file we modified in Step 1, and paste it into the ..\tmp\windows\system32 folder, overwriting the previous file.
In our example we would:
- Browse to the d:\deployment_share\cloudready folder
- Find & copy the startnet.cmd into our clipboard, then
- Paste it into d:\deployment_share\cloudready\windows\system32\, saying ‘Yes’ to overwriting any existing files.
7. Once copied, be sure to close any open explorer windows, notepad.exe instances, or open files accessing the tmp subfolder. The unmount process in the next step is very particular that no files are in use, and will respond with an error and refuse to unmount the .wim file.
8. Going back to the original command prompt, execute the following command, substituting the actual local path of the tmp folder containing the cloudready files:
imagex /unmount /commit [local path to tmp folder]
Explanation: This command will again call the imagex utility, unmount and update our cloudready.wim file with the change we made to include your now customized startnet.cmd file.
- In this example, our command would read:
imagex /unmount /commit z:\deployment_share\cloudready\tmp
9. Once the .wim file is unmounted successfully, the process of editing the boot image is now complete! Proceed to step 3.
03. Enable Boot Image for WDS
Now that we have our custom CloudReady .wim file, let’s set it up as an available boot image within your existing WDS infrastructure.
- Launch the Windows instance hosting your WDS infrastructure and open Windows Deployment Services.
- Expand the server that currently hosts your PXE images.
- Right click "Boot Images" and select “Add Boot Image”
- Browse to the location of the cloudready.wim file that you previously modified.
Note: If the working directory for the CloudReady share created in previous steps is on a different server than the WDS server, the cloudready.wim file can be copied to the WDS server’s local drive; or can be mapped remotely using the UNC path of the server hosting the .wim file. During this process of creating the boot image, the .wim file will be consumed by WDS and stored locally within its own structure.
- Click Next
- Change the image name to convenient identifier, like “CloudReady-BIOS” or “CloudReady-UEFI”, and click Next:
- Confirm that everything looks accurate and click Next:
- Observe progress; this process should typically take less than 5 minutes to complete:
- Click Finish:
- The image we named in the previous steps, should now be visible under boot images as shown in the example below:
04. Deploy CloudReady on a Client Machine
The last and final step!
- Select a target device for CloudReady imaging.
- Boot the device using PXE or Network boot method.
Note: Ensure that BIOS settings properly configured in that,
- Network/PXE boot is available as a boot method in BIOS.
- CloudReady image you’ve defined, matches the BIOS of the device (legacy or UEFI).
- Depending on whether or not your environment has more than one WDS boot image defined, the process will go slightly different.
a. If CloudReady is the only boot image available, it will boot directly into our new image, and deployment will proceed automatically:
b. If there are multiple boot images available, choose the CloudReady image we define in Step 3. Deployment will then proceed automatically:
- Once the WinPE environment is loaded, you’ll see a black command prompt as shown below:
- Upon successful completion, the computer will reboot with CloudReady installed!
That’s it! You’ve deployed CloudReady using WDS. As always, we’re always to provide support or simply to just hear your feedback. Feel free to reach out: https://neverware.com/contact
To facilitate large-scale deployments, CloudReady can be deployed using Microsoft System Center Configuration Manager (SCCM). Neverware provides guidance, custom SCCM-deployable disk images, and an easily importable SCCM task sequence to customers upon request. To discuss deploying CloudReady in your organization using SCCM, please contact our sales team.
Other tools that facilitate whole/raw disk imaging and PXE-based network deployment of those images to disks may be usable as deployment methods for CloudReady. Altiris, Symantec Ghost, FOG, and others are examples.
Although Neverware is unable to officially support these alternative deployment methods, they may work.
For all instances of mass-deployment, it is critical that you follow these general guidelines:
- The image you deploy should not be a CloudReady Installer image (~6 GB size) - those images are meant only for USB installation.
You can capture an image from a device after installing to it via USB, or use deployment images provided by Neverware.
- If you capture an image for deployment, make sure to capture the image immediately after USB install completes, but before that device has been powered on for the first time. Capturing an image that has already been turned on once will lead to problems with both Neverware and Google licensing and management.
- Make sure you account for disk capacity and boot mode (legacy vs uefi) - you may need to deploy a different image to different devices based on these variations.