locked
New ConfigMgr environment-Windows upgrade deployment-discovered system records from AD with no MAC address RRS feed

  • Question

  • Hello, although this has somewhat been already discussed in previous forum posts, the solution I saw will not work for me so just wanted to check for alternative solutions.

    So right now I have a new ConfigMgr 2012 environment that has performed a system discovery in AD and found all of my computer accounts but of course the records are missing MAC address.  I need the MAC address for these objects for our upcoming Windows upgrade, that's when these systems will become ConfigMgr 2012 clients.  Since the existing computers that we are planning on upgrading are currently XP and we have our ConfigMgr site setup for HTTPS and we have a Windows 2012 CA, our XP clients cannot become ConfigMgr 2012 clients due to new default security features in Windows 2012 CS.  Windows XP cannot enroll in the client authentication certificate.  So since my existing XP systems cannot become clients to get the MAC address in the system records so I can image them, what's the best way to get them in there?  You also might suggest using unknown computer support, however I have my task sequence for OSD setup to where it auto-names the machine and auto-joins the domain based on the existence of an associated record in ConfigMgr based on the MAC/Computer name association.  Currently if I delete one of the discovered records, then import a computer with MAC, after the next system discovery now there is a duplicate record, the "Manual Machine Entry" one, and the "SMS_AD_SYSTEM_DISCOVERY_AGENT" one.  With all this in mind, this option is the best thing that I can think of right now:

    -Turn off system discovery (To prevent all the duplicate records from showing up after the next step of manual import and the next system discovery)

    -Manually import all computers with their MAC address using the "Import Computer Information" utility (I already know the MAC addresses of all computers)

    -Complete the Windows upgrade on all computers (over a few weeks)

    -Then once all systems have been upgraded, reenable system discovery

    Do you feel that's my best option, or can you think of another? 

    Other options I don't really want to do are:

    -Change the security on my Certificate Authority to allow XP to autoenroll in their client authentication certificates

    -Redesign the deployment task sequences to allow for unknown computers to be reimaged

    -Disable HTTPS in ConfigMgr

    These 3 options are less than ideal to me for security and/or for the fact these are bigger changes than the issue justifies, such as I can't justify the time to spend changing all of my task sequences and my reimaging processes that work so nicely right now, just to resolve this one issue that will only affect me right now.

    Any thoughts/suggestions will be much appreciated.

    Thanks!

    Tuesday, March 4, 2014 11:18 PM

Answers

  • Is there a specific reason you are using HTTPS client communication?

    What's your standard for naming computers? Most folks use a script within the task sequence to do this automatically. As for joining the domain, same question as above, what are your requirements?

    If you already have a list of all computers and their MACs, I would just use the Import Computer process initially though and leave AD discovery off initially. You could also use a custom DDR to simply add the MAC to the AD created resource.


    Jason | http://blog.configmgrftw.com

    Wednesday, March 5, 2014 1:03 AM
  • For the HTTPS client communication, absolutely on the recommendation to not enable it. HTTPS client communication is a means to an end -- it is not a security mode or mechanism. It does not even protect all of your client traffic and the once the data hits the DB, it's not encrypted there either. Honestly, it's more about integrity than protection when content is transmitted over the Internet (which is part of security also though). That's not to say that it can't increase your security posture, but security is about mitigating risk so the question really is what risk are you trying to mitigate by enabling it? If there's no risk mitigated, then you shouldn't even consider doing it.

    The biggest downfall to enabling HTTPS client communication is the added complexity and overhead involved that most folks are simply not equipped to handle or troubleshoot when something goes wrong.

    Correct on re-enabling System Discovery, it should just work once you re-enable it.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Juke Chou Sunday, March 30, 2014 2:56 PM
    Wednesday, March 5, 2014 5:02 PM

All replies

  • Is there a specific reason you are using HTTPS client communication?

    What's your standard for naming computers? Most folks use a script within the task sequence to do this automatically. As for joining the domain, same question as above, what are your requirements?

    If you already have a list of all computers and their MACs, I would just use the Import Computer process initially though and leave AD discovery off initially. You could also use a custom DDR to simply add the MAC to the AD created resource.


    Jason | http://blog.configmgrftw.com

    Wednesday, March 5, 2014 1:03 AM
  • Hello Jason,

    Per your questions:

    I didn't setup HTTPS for anything out of the ordinary, just trying to follow best practices for security.

    Standard naming convention for computers is very simple same two letters for all systems XX followed by a unique four digit number, ex: XX1234

    All computer accounts are in the same OU

    I am very interested in the possible custom DDR solution you proposed, that would be really nice to be able to add the MAC to the existing records, do you have any additional information on how to do that?

    Thanks!

    Wednesday, March 5, 2014 3:33 PM
  • First, it's not a best practice for security to enable HTTPS client communication. It's not like you're protecting PII or anything.

    Next, it sounds like your naming can easily be done with a simple script and there's no reason to used a pre-staged or preexisting name so unknown computer support would be fine.

    Finally, my webcast I did a couple of weeks ago for Secunia had additional info on custom DDRs (I don't think it's been posted yet though and I haven't had a chance to do a follow-up blog post yet but will in the near future).


    Jason | http://blog.configmgrftw.com

    Wednesday, March 5, 2014 3:54 PM
  • Thanks Jason, I don't think I've ever actually seen this in writing (not that I'm doubting you cause I am certainly NOT) "it's not a best practice for security to enable HTTPS client communication".  So I'm assuming you actually recommend that people do not enable HTTPS unless they really HAVE to?  Other than this little XP snafu, is there any downfall to having this enabled for all available functions (MP/DP/etc...)?

    Thanks for putting together a webcast for that, I'll keep my eye out for it on your blog...

    Due to our very short timeline before starting our Windows upgrade project which won't really allow time to develop unknown computer support in time, and the fact that your custom DDR documentation isn't available yet, I suppose I'll go ahead and go with disabling system discovery, delete discovered records, then the manual import.  At least just for while were going through the project.  Once the project is over I can just reenable system discovery as normal without any negative reporcussions, correct?

    Wednesday, March 5, 2014 4:55 PM
  • For the HTTPS client communication, absolutely on the recommendation to not enable it. HTTPS client communication is a means to an end -- it is not a security mode or mechanism. It does not even protect all of your client traffic and the once the data hits the DB, it's not encrypted there either. Honestly, it's more about integrity than protection when content is transmitted over the Internet (which is part of security also though). That's not to say that it can't increase your security posture, but security is about mitigating risk so the question really is what risk are you trying to mitigate by enabling it? If there's no risk mitigated, then you shouldn't even consider doing it.

    The biggest downfall to enabling HTTPS client communication is the added complexity and overhead involved that most folks are simply not equipped to handle or troubleshoot when something goes wrong.

    Correct on re-enabling System Discovery, it should just work once you re-enable it.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Juke Chou Sunday, March 30, 2014 2:56 PM
    Wednesday, March 5, 2014 5:02 PM