Home / OCI

OCITroubleshootingBeginner

OCI Windows instance not activated: KMS on 169.254.169.253, firewall rules, time and custom images

Windows on OCI shows "Activate Windows" or error 0xC004F074. Check the KMS address, the outbound path to 169.254.169.253:1688, the clock and the product key, then activate again with slmgr.

Deepak Bhardwaj6 min read

Applies toOCI Compute with Windows Server 2016/2019/2022/2025 platform images (license included) and imported custom Windows images

Symptom

A Windows Server instance on OCI shows the "Activate Windows" watermark, or Settings reports Windows isn't activated. slmgr /ato fails with one of these errors:

  • 0xC004F074: no Key Management Service (KMS) could be contacted
  • 0xC004F06C: the KMS host rejected the request timestamp
  • 0xC004F035 or a similar product key error: the image has no KMS client (GVLK) key

OCI Windows platform images are license-included. They activate against an Oracle-run Microsoft KMS host on the link-local address 169.254.169.253, TCP 1688. When activation breaks, the cause is nearly always one of four things. The instance is pointed at the wrong KMS host, it can't reach 169.254.169.253, its clock is wrong, or it has the wrong kind of product key.

Tip

If you can't RDP in, run every command below through Run Command or the console connection. The steps are the same.

Quick checks

Open an elevated PowerShell prompt:

# Activation state: LicenseStatus 1 = Licensed, other values = not licensed or in grace period
Get-CimInstance SoftwareLicensingProduct -Filter "PartialProductKey IS NOT NULL AND Name LIKE 'Windows%'" |
  Select-Object Name, Description, LicenseStatus, PartialProductKey

# Detailed view, including the KMS host the client is using
cscript //nologo C:\Windows\System32\slmgr.vbs /dlv

In the /dlv output, look at:

  • Description: it should contain VOLUME_KMSCLIENT channel. RETAIL or MAK means a different key type (see the custom images section below).
  • KMS machine name from DNS or Registered KMS machine name: this should be 169.254.169.253:1688. If it shows a corporate host name, see the domain section below.

Cause and fix table

Symptom Cause Fix
0xC004F074, the registered KMS host is a corporate server Domain-joined instance found an on-prem KMS through the _vlmcs._tcp DNS SRV record Set the KMS host explicitly to 169.254.169.253:1688
0xC004F074, the host is correct Windows Firewall, a hardening GPO or third-party security software blocks outbound traffic to 169.254.169.253 Allow outbound TCP 1688 to 169.254.169.253
0xC004F074 after you installed VPN, proxy or routing software The route to 169.254.0.0/16 now goes out the wrong interface Fix the route so link-local traffic uses the primary VNIC
0xC004F06C Clock or time zone is wrong Fix time sync, then activate again
Description shows RETAIL or MAK, or the key is rejected Imported custom image without a KMS client key Install the GVLK for that edition
Instance is a BYOL import Bring-your-own-license images shouldn't use Oracle's KMS Activate with your own license method

Fix 1: point the instance at the OCI KMS host

cscript //nologo C:\Windows\System32\slmgr.vbs /skms 169.254.169.253:1688
cscript //nologo C:\Windows\System32\slmgr.vbs /ato

Domain-joined instances are the most common problem. If your Active Directory publishes a _vlmcs._tcp SRV record for an on-prem KMS host, Windows tries that host first. It often can't reach it from OCI, or that host isn't licensed for the edition. Setting /skms stores the host explicitly and stops automatic discovery from overriding it. If you manage activation by GPO, put the same value in the policy, or the next refresh puts the old host back.

Fix 2: prove the network path to 169.254.169.253

Test-NetConnection 169.254.169.253 -Port 1688

# Which interface and next hop Windows uses for the KMS address
Find-NetRoute -RemoteIPAddress 169.254.169.253 | Select-Object InterfaceAlias, NextHop, RouteMetric

route print 169.254.*

TcpTestSucceeded : False means the problem is inside the guest.

  • Windows Firewall or a hardening baseline. Oracle's platform image documentation says you can change the image's firewall rules, but you must not restrict link-local traffic to 169.254.169.253, or activation fails. CIS-style baselines that set outbound to Block need an explicit allow:
New-NetFirewallRule -DisplayName "OCI KMS activation" -Direction Outbound `
  -Protocol TCP -RemoteAddress 169.254.169.253 -RemotePort 1688 -Action Allow
  • Endpoint security or a proxy agent that intercepts outbound TCP. Add an exclusion for 169.254.169.253.
  • Routes. The route for 169.254.0.0/16 should use the primary VNIC. VPN clients, a second VNIC configured by hand, or a static route added during a migration can send it somewhere else. Remove the wrong route with Remove-NetRoute and test again.

While you're in the guest, also check that the instance can reach the metadata service on 169.254.169.254. If both link-local addresses fail, the route or firewall is broken for the whole 169.254.0.0/16 range, not just for KMS.

Fix 3: correct the clock

KMS rejects requests when the client's time is too far from the host's. Oracle's custom image guide says the instance time must match its time zone for KMS registration to work.

w32tm /query /status
w32tm /query /source
tzutil /g

# Use the OCI NTP service, resync, then activate again
w32tm /config /manualpeerlist:169.254.169.254 /syncfromflags:manual /update
w32tm /resync /force
cscript //nologo C:\Windows\System32\slmgr.vbs /ato

On a domain member, time normally comes from the domain hierarchy. Fix the time source on the domain controllers rather than overriding a single member server.

Fix 4: custom images need a KMS client key

Imported images (VMware or Hyper-V exports, for example) usually keep the original retail or MAK key. If you imported the image to run as license-included on OCI, Oracle's post-import steps are: install the KMS client setup key (GVLK) for that exact Windows version and edition, point the instance at the KMS host, then activate:

# Use the GVLK for your exact edition from Microsoft's "KMS client activation and product keys" page
cscript //nologo C:\Windows\System32\slmgr.vbs /ipk <GVLK-for-this-edition>
cscript //nologo C:\Windows\System32\slmgr.vbs /skms 169.254.169.253:1688
cscript //nologo C:\Windows\System32\slmgr.vbs /ato

Warning

Check the licensing model before you change the key. A BYOL image activated with your own license shouldn't be switched to Oracle's KMS. The licensing model also decides what you're billed for that instance. Check with whoever owns Microsoft licensing for the tenancy.

Evaluation editions can't be activated with a GVLK. Convert them with DISM (DISM /online /Set-Edition) first, or rebuild from a platform image.

Verify

cscript //nologo C:\Windows\System32\slmgr.vbs /dli

The output should show License Status: Licensed. The KMS client renews automatically, so as long as the path to 169.254.169.253:1688 stays open, the instance stays activated.

Prevent it next time

  • Add the outbound allow rule for 169.254.169.253:1688 (and for 169.254.169.254) to your Windows hardening baseline, so a GPO refresh can't remove it.
  • For domain-joined OCI instances, set the KMS host by GPO or in your build script. Don't rely on SRV discovery.
  • Bake the GVLK, /skms and an activation check into your custom image pipeline, and test a fresh launch before you publish the image.
  • Monitor activation. A scheduled Run Command or configuration management check that reports LicenseStatus finds problems before the grace period ends and users see the watermark.

Related fixes