locked
Multiple _vlmcs SRV records atuto created in third party DNS by Domain controllers. RRS feed

  • Question

  • Hi, when I run the following command to confirm if your kms host has successfully created a record in our third party DNS. I receive the following response

    I want to confirm if it is normal for Windows 2008 R2 Domain Controllers to auto create _vlmcs SRV records.  The domain contollers are all volume_kmsclients.  The software licensing service is running on them (slsvc).  Each DC is in a different subnet even though the domain name remains the same.

    The actual KMS host is highlighted in BOLD it has the software protection service running on it. (sppsvc) - what's the difference??

    thanks

     

    (I also want the _vlmcs record to use an dns alias, can I update the record myself or would I have to create manual entry)

     

    nslookup -type=srv _vlmcs._tcp.blah.int

    Server:  wptxdc1.blah.int

    Address:  10.128.17.10

     

    Non-authoritative answer:

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wrwcdc1.blah.int

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wancydc1.blah.int

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wbuchdc1.blah.int

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wptxkms1.ptx.blah.int

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wphxdc1.blah.int

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wphxdc2.blah.int

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wphxdc3.blah.int

    _vlmcs._tcp.blah.int   SRV service location:

              priority       = 0

              weight         = 0

              port           = 1688

              svr hostname   = wptxdc2.blah.int

     

    wrwcdc1.blah.int       internet address = 10.130.17.10

    wancydc1.blah.int      internet address = 10.131.17.10

    wbuchdc1.blah.int      internet address = 10.133.17.10

    wphxdc1.blah.int       internet address = 10.129.17.10

    wphxdc2.blah.int       internet address = 10.129.17.11

    wphxdc3.blah.int       internet address = 10.228.1.10

    wptxdc2.blah.int       internet address = 10.128.17.11


    Thursday, October 28, 2010 1:53 PM

Answers

  • Hello Alex,

    KMS clients should not be updating _vlmsc records, only KMS host machines should be doing.

    What we have seen however is that the KMS host key has been used accidently on multiple machines, creating KMS hosts of machine that should be KMS clients.

    Even if the machine is then converted back to a KMS client, the cache may attempt to write the record.

    Rebooting the server should flush the cache.  You can try stopping the software protection service and restarting, it may stop it as well.

    On the machine attempting to write the record, let's first verify they are KMS clients.

    Open an elevated CMD prompt and run slmgr /dlv

    What is on the description line of the output of each of those machines?

     


    Thanks, Darrell Gorter This posting is provided "AS IS" with no warranties, and confers no rights. VAMT - Volume Activation Management Tool - Download link http://www.microsoft.com/downloads/details.aspx?FamilyID=ec7156d2-2864-49ee-bfcb-777b898ad582&displaylang=en
    Thursday, October 28, 2010 8:20 PM