When you generate artifacts for Windows workloads, the artifacts are zipped
and copied into a Cloud Storage bucket as an intermediate location
that you can download. This zip file contains a Dockerfile, the
and several directories and files that are extracted from the source that
you then use to build the Windows container.
Before you begin
Before building the Windows container, you should have first:
Building containers for a single Windows version or for multiple versions
The procedure shown below lets you build a container for a single version of Windows.
That means you download the
artifacts.zip file and build the container image
on a Windows machine running the same Windows version as your container's target machine.
In many situations, a single version of the Windows container is sufficient.
Alternatively, you can use the procedure described in Building Windows Server multi-arch images to build Windows container images that target multiple Windows versions. Specifically, on that page, use the Building multi-arch images using the Cloud Build gke-windows-builder procedure.
Determine the URL of the migration artifacts zip file
The migration artifacts are contained in a single zip file named
that you must download as part of building the container image. This step describes
how to determine the location of the
artifacts.zip file. You perform the actual download
on a Windows machine as described below.
When the migration completes, you should see a message such as the following when you request status:
migctl migration status my-migration NAME CURRENT-OPERATION PROGRESS STEP STATUS AGE my-migration GenerateArtifacts [1/1] ExtractImage Completed 14m23s
migctl migration get-artifacts my-migration Artifacts are accessible through `gsutil cp gs://PATH/artifacts.zip ./`
When the migration completes, you see Artifacts generated in the Status column of the migration. To download all migration artifacts:
Open the Migrate for Anthos and GKE page in the Cloud Console.
Click the Migrations tab to display a table containing the available migrations.
Click the migration Name in the row for the desired migration. The migration Details tab opens.
Select the Artifacts tab.
Select Container artifacts zip to view the URL of the
Use that URL in the following procedure to download the
Building the container image
Using the migration artifacts in the zip file, build a container image that you can then deploy to your GKE cluster.
You must run
docker build on a Windows version that is the same as the version
used by the target container.
In Cloud Shell, create a Windows Server instance on Compute Engine. For example, use the following command to create an instance:
gcloud beta compute instances create win-builder-1 \ --project=project-name --zone=gcp-zone \ --machine-type=e2-standard-4 --subnet=default --scopes=cloud-platform \ --image=windows-server-2019-dc-for-containers-v20210413 --image-project=windows-cloud \ --boot-disk-size=64GB --boot-disk-type=pd-ssd
To determine when the server instance is ready for an RDP connection, run the following command at your Cloud Shell command line:
gcloud compute instances get-serial-port-output win-builder-1 --zone=gcp-zone
Repeat the command until you see the following in the command output, which tells you that the OS components have initialized and the Windows Server is ready to accept your RDP connection:
Instance setup finished. win-builder-1 is ready to use.
In the Cloud Console, navigate to the Compute Engine page.
For win-builder-1 click RDP > Set Windows Password to generate a password for this Windows instance.
Copy the username and password and save it so you can log into the instance.
Click RDP to connect to the Windows server.
On the login page, enter the username and password that you saved previously.
powershellon the Windows instance. You can do this by entering the command
powershellin a terminal window, or by using the Windows GUI (if the Windows machine is confugred to include a GUI).
To account for long paths during zip operations, set the following registry key and restart the machine:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem Value: LongPathsEnabled Data: 1
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1 -Type DWord Restart-Computer
For more, see Enable Long Paths in Windows 10, Version 1607, and Later.
The Windows machine restarts. When the machine is available, RDP into it again, using the same password you used earlier, and restart
Use gsutil to download the
artifacts.zipfile using the URL you determined above in Determine the URL of the migration artifacts zip file:
gsutil cp gs://PATH/artifacts.zip ./
Using PowerShell, expand the
artifacts.zipfile you downloaded above with a command such as the following:
Optionally configure logging to Cloud Logging by editing the
See Configuring logging to Cloud Logging below for more.
Optionally edit the
set_acls.batscript to set access control list (ACL) permissions for the Windows container.
See Setting ACLs below for more.
Using the Dockerfile included in the zip file, use
docker buildto build an image from the extracted files:
docker build -t gcr.io/myproject/myimagename:v1.0.0 .\artifacts\
Authenticate with the Container Registry:
gcloud auth configure-docker
docker pushto push the image to the Container Registry:
docker push gcr.io/myproject/myimagename:v1.0.0
Configuring logging to Cloud Logging
Migrate for Anthos and GKE uses the LogMonitor tool to extract logs from a Windows container and forward them to your GKE cluster. These logs are then automatically forwarded to Cloud Logging, which provides a suite of tools to monitor your containers.
By default Migrate for Anthos and GKE enables IIS logging to monitor the IIS logs, and also forwards the Application/System event logs to Cloud Logging.
Expanding the generated
artifacts.zip file creates several directories, including
m4a directory. Included in the
m4a directory is the
file that you can edit to control logging.
For more on editing
Authoring a Config File.
Some IIS applications require that you set specific access control lists (ACL)
permissions on files and folders in order for the applications to perform correctly.
Migrate for Anthos and GKE automatically scans all migrated IIS applications and adds any specific
permissions defined in the source VM that apply to IIS accounts (the
IIS_IUSRS group) and applies them to the copied files and directories
in the generated container image.
Because Windows container images do not support setting ACLs as part of the Docker
the ACLs are set in a script called
set_acls.bat. Migrate for Anthos and GKE automatically
set_acls.bat in the root directory of expanded
Migrate for Anthos and GKE then calls
set_acls.bat when you execute the
docker build command.
set_acls.bat to add or remove custom permissions, or edit permissions that
are not related to specific IIS users and therefore were not detected by Migrate for Anthos and GKE.
The script uses the Windows built-in icacls tool to set permissions.
About the .NET Global Assembly Cache
Migrate for Anthos and GKE scans the source image .NET Global Assembly Cache (GAC)
for .NET resources that are installed on the source machine and not available
as part of the official images. Any discovered DLL is copied into the Docker context
and installed as part of the building of the target image by a utility script
All .NET assemblies are copied into the Docker context under the
To remove assemblies from the image, delete them from the