Share via

Cleanup old KMS _VLMCS Record in DNS

Anonymous
2024-01-03T21:38:21+00:00

I have noticed in my environment Servers/Workstations are not complaining about “Activate Windows”, even though slmgr /dlv says its registered to a VOLUME_KMS_WS16_channel to a KMS host that does not exist (via NSLOOKUP -type=all _vlmcs._tcp).

Then, I found that the existing Servers/Workstations must be using the BackupProductKeyDefauly in the registry under SoftwareProtectionPlatform.  I think that is why they are not complaining!?  At one time, they must have registered to a KMS host to get a key.  So, I think we can safely assume that licensing will not break in the existing environment when we implement the new KMS/ADBA solution. True? And should I clean up the _VLMCS record somehow?

Windows for business | Windows Server | Devices and deployment | Licensing and activation

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments
Accepted answer
  1. Anonymous
    2024-01-05T02:29:38+00:00

    Hi Dale 76118,

    once you have deployed a new KMS host with your KMS keys, the endpoints that were previously activated with MAK keys will continue to use those MAK keys unless you force them to use the KMS keys. The endpoints will not automatically detect the KMS host in AD/DNS and start using the KMS keys.

    Regarding the Win 10 workstations that may not communicate with AD beyond 180 days, if a new workstation is assigned a KMS key via ADBA and does not communicate with AD, it will become unlicensed after 180 days. To avoid this, you can configure the workstation to communicate with the KMS host at least once every 180 days to maintain activation.

    Hope it helps.

    1 person found this answer helpful.
    0 comments
Accepted answer
  1. Anonymous
    2024-01-04T01:43:40+00:00

    Hi Dale 76118,

    yes, it is possible that the existing Servers/Workstations are using the BackupProductKeyDefault in the registry under SoftwareProtectionPlatform, which is why they are not complaining about activation. However, it is recommended to ensure that all systems are properly activated and licensed to avoid any potential issues in the future.

    As for cleaning up the _VLMCS record, you can delete it from the DNS server using the DNS Manager console. To do this, open the console, expand the Forward Lookup Zones folder, and then locate the zone that contains the _vlmcs._tcp record. Right-click the record and select Delete. This will remove the record from the DNS server.

    For more information about DNS related issues, please visit Guidelines for troubleshooting DNS-related activation issues | Microsoft Learn.

    Hope it helps.

    Best regards,

    Lei

    1 person found this answer helpful.
    0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2024-01-04T15:58:35+00:00

    Thank you for the response Lei.

    Another follow-up question...

    We have other Win2016/2019 Servers and Win10 Workstations that were assigned MAK keys. What is the impact of those MAK licensed endpoints after I have deployed a new KMS Host (Active Directory-Based Authentication) with our KMS keys? Will they continue to use MAK keys, or does the endpoints detect KMS in AD/DNS and start using those keys? I assume no impact and they will continue to use the MAK keys, unless I force the endpoints to use the ADBA keys. Correct?

    Also, some of the Win 10 Workstations may not communicate with AD beyond 180 days. If a new Win10 Workstation is assigned a KMS key via ADBA, and does not communicate with AD, what is the effect after 180 days?

    Thank you!!

    0 comments
  2. Anonymous
    2024-01-08T06:04:14+00:00

    Hi Dale,

    if you have already activated your Windows Server and Windows 10 devices using MAK keys, they will continue to use those keys until they are reactivated or until the MAK key limit is reached. The endpoints will not automatically detect the KMS host in AD/DNS and start using those keys. If you want to switch your endpoints to use the KMS keys, you will need to run a script or use Group Policy to force the endpoints to use the KMS host.

    Regarding your second question, if a Windows 10 workstation is assigned a KMS key via ADBA and does not communicate with AD beyond 180 days, it will become unlicensed and enter a 30-day grace period. During this grace period, the workstation will continue to function normally, but it will display a warning message indicating that it is not activated. If the workstation does not communicate with AD and activate within the 30-day grace period, it will enter a reduced functionality mode, where some features will be disabled until it is activated.

    0 comments