none
netdom computername NEWSERV /add:oldserv.sub.main.tld makes "cannot create a file when that file already exists" error RRS feed

  • Question

  • Standing up a new print server, and I thought it would be easy enough to use the instructions here to get HOST and RestrictedKrbHost from the old server name, pointed to the NEWSERV name. So people could continue to use their old sharenames on Windows and MacOS, and they would pass flawlessly through to NEWSERV and be processed.

    However, I didn't count on the fact that a decade ago, OLDSERV was a domain controller. Hasn't been for 8 years now, but something seems to be up in DNS in the sense that even when i set my TTL to 5 seconds for OLDSERV's entries and let it time out, then delete the entry in DNS, running a dig command on the DNS servers still points to the OLDSERV ip address. Even my boss was flummoxed by this, and he's been managing DNS for twenty years - but never messing around with former domain controllers.

    In my testing, using netdom computername NEWSERV /add:oldservclonetest.sub.main.tld (i cloned the VM of the old print server to a new name, then tried all this before doing it in production) worked perfectly, and setspn NEWSERV -L perfectly listed both newserv and oldserv SPN listings.

    But try as I might, this error message persists - "cannot create a file when that file already exists" whenever I run it on the actual OLDSERV name that I need to be handled by NEWSERV.

    Is my thought that this is caused by this remaining DNS entry being stuck somewhere in our 2 DNS servers, likely valid? Is this possibly because by the fact that OLDSERV used to be a domain controller? If so, what is a safe step to do, in order to fully get rid of ALL old entries to OLDSERV and its old IP address?

    Once we do that... I'm hoping that the netdom command will run, like it did on my test!

    Thursday, February 21, 2019 7:18 PM

Answers

  • Okay, so what ended up fixing this for me was listed right here in this link:

    Solution:

    The user ID must have Write permissions to msDS-AdditionalDnsHostName on the object within Active Directory. You can see the modification attempt via the packet capture data below.

    I went into AD attributes for the NEWSERV, and found that the msDS-AdditionalDnsHostName was already populated with the TESTNEWSERV name that I had used a month ago to confirm that this entire setup was possible. Once I cleared that entry entirely (TESTNEWSERV had already been deleted out of AD weeks ago), immediately the netdom command worked.

    It's a headscratcher as to why that made the difference, but just in case anyone else has the issue...


    • Marked as answer by MD5Hash Monday, March 4, 2019 4:24 PM
    • Edited by MD5Hash Monday, March 4, 2019 4:25 PM
    Monday, March 4, 2019 4:24 PM

All replies

  • Hi,

    Thanks for posting in the forum.

    Based on our knowledge, the issue may be related to metadata cleanup. Once we did a forced removal of the DC, we need to clean the data in AD data base to make sure there is no residual data in it.

    Here is the official article about how to Clean up Active Directory Domain Controller server metadata:

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup

    Regards,

    Zoe

     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, February 22, 2019 7:00 AM
  • Hi,

    Just checking in to see if the information provided was helpful.

    Please let us know if you would like further assistance.

    Best Regards,

    Zoe


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, February 25, 2019 6:12 AM
  • Hi,

    Was your issue resolved?

    If the information provided was helpful, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    Thank you for your understanding and support.

    Best Regards,

    Zoe


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, February 27, 2019 6:20 AM
  • Hi,

    As this thread has been quiet for a while, we will propose the solution as answer. If you need further help, please feel free to reply this post directly so we will be notified to follow it up. You can also choose to unpropose the answer as you wish.

    BTW, we'd love to hear your feedback about the solution. By sharing your experience, you can help other community members facing similar problems. Thanks for your understanding and efforts.

    Best Regards,

    Zoe


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, March 1, 2019 6:51 AM
  • Okay, so what ended up fixing this for me was listed right here in this link:

    Solution:

    The user ID must have Write permissions to msDS-AdditionalDnsHostName on the object within Active Directory. You can see the modification attempt via the packet capture data below.

    I went into AD attributes for the NEWSERV, and found that the msDS-AdditionalDnsHostName was already populated with the TESTNEWSERV name that I had used a month ago to confirm that this entire setup was possible. Once I cleared that entry entirely (TESTNEWSERV had already been deleted out of AD weeks ago), immediately the netdom command worked.

    It's a headscratcher as to why that made the difference, but just in case anyone else has the issue...


    • Marked as answer by MD5Hash Monday, March 4, 2019 4:24 PM
    • Edited by MD5Hash Monday, March 4, 2019 4:25 PM
    Monday, March 4, 2019 4:24 PM