Non-Domain for the millionth time...

Comments

15 comments

  • Shane Corellian

    Hi Doug,

    One of the biggest gotchas when it comes to managing non-domain computers has to do with Remote UAC. There is a registry setting you need to modify to allow a local account to access the Admin shares on a target.

    http://support.adminarsenal.com/entries/20828513-Can-t-access-ADMIN-share-using-a-local-user-account

    After that, make sure that the non-domain computer is registered with DNS.

    Also make sure that the appropriate firewall settings are enabled. Since you don't use GPOs on these machines you may need to use GPEDIT.msc to set the exceptions manually.

    http://support.adminarsenal.com/entries/21531976-Windows-Firewall-Ports-and-Exceptions

     

    1
    Comment actions Permalink
  • Brigg Angus

    Okay. To recap all the right things:
    1. You can ping the machine
    2. The machine name and IP match as expected for NetBT resolution
    3. DNS resolution works
    4. Firewall is allowing the necessary ports
    5. LocalAccountTokenFilterPolicy is set to "1" in the registry
    6. \\TARGET\ADMIN$ is accessible
    7. The PDQ user is a part of the local target's lusrmgr.msc > Groups > Administrators group

    If all of things are true, would you bypass DNS entirely by adding the machine name and IP to the %WINDIR%\System32\drivers\etc\hosts file? See if the results differ.

    If that doesn't make a difference, would you install PDQ Inventory on another machine. It can be just a basic install since we only need to see if the behavior is repeatable from a different instance. If it is, then we need to look at the target: the OS, firewall, AV, proxy, local GPO/SRP, etc. If it's not repeatable, then we can investigate the existing Inventory instance.

    1
    Comment actions Permalink
  • Stephen Valdinger

    See every time I need to do something more than once it turns into a powershell script haha. I don't care if it is once a month, or once a year. I automate EVERYTHING. Mostly because I'm a weirdo like that and I like to write Powershell, but still. haha.

    1
    Comment actions Permalink
  • Doug Kinsey

    Thanks, Shane.  

     

    I have allowed access, double checked DNS, checked firewall, set Standard Profile Group Policy, and still no dice.  The PCs add to the list with no problem at all, but that is all the farther I get.  

    0
    Comment actions Permalink
  • Brigg Angus

    There are a few other things we can check as well:

    1. Would you click on one of the offending machines and then click on Inventory Help > Open Remote Repair and analyze the machine? What errors, if any, do you get?

    2. Open a command prompt on the Inventory console machine and run the following:

    nbtstat -A <IPaddress>

    Where <IPaddress> is the IP of one of the machines you cannot scan. Let us know the result.

    edit:

    3. Can you access \\<IPaddress>\ADMIN$ of one of the non-domain machines?

    0
    Comment actions Permalink
  • Doug Kinsey

    0 Tests failed when I analyzed the machine.  The result of nbtstat gives me the machine name/groups and MAC address.  Yes, I can access the ADMIN$ on the remote machine, but I am prompted for username/password.

    0
    Comment actions Permalink
  • Brigg Angus

    This is a bit odd, I'll admit. Everything appears to be working as it should, and the magic should happen. Maybe something basic is amiss. Can you ping the target from the PDQ console machine?

    0
    Comment actions Permalink
  • Doug Kinsey

    I am able to ping the machine, yes.  I agree it must be something basic that is being overlooked, but perhaps I am just not meant to track non-domain equipment the easy way!

    0
    Comment actions Permalink
  • Doug Kinsey

    Well, adding the machine name to the hosts file did the trick.

    0
    Comment actions Permalink
  • Doug Kinsey

    However, when the next AD sync occurred, it erased the non-domain machine from inventory.

    0
    Comment actions Permalink
  • Shane Corellian

    Doug, if you are going to have non-domain machines in Inventory and you use AD Sync you need to set the Delete Mode to Mixed Sync. It looks like you use the Full Sync which is only appropriate if all the computers in PDQ Inventory are going to be in your Sync containers in AD.

    AD_Sync_Mixed.png

    0
    Comment actions Permalink
  • Doug Kinsey

    Thanks, Shane.  Figured that one out after a few minutes of head scratching.  

    0
    Comment actions Permalink
  • Jeff Lamb

    Guys


    FWIW
    50% of the machines i manage with PDQ are non-domain joined

    To manage these computers AND use the FULL AD Sync, I manually create a machine account in its own AD OU.

    Each machine is deployed with a DNS Suffix configured in the NIC




    To ensure it works hand-in-hand with DNS, with Advanced Features enabled, i open the attribute Editor of the machine account and set the dnsHostName to the machine_account_name.domain_name.com

    now, i have a machine account, linked to DNS, which will not be removed whenever i do a full AD sync.

    Hope this helps.




    JC

    0
    Comment actions Permalink
  • Stephen Valdinger

    Please tell me you are doing all of that with a Powershell script. Please oh please oh please. That's SO much data to make sure is right in many places. 1 script with a couple of steps would streamline that and eliminate completely errors in the deployment. If you need help with such a thing, please reach out. I or others are willing to help get you there. That gives me a headache just thinking about it.

    0
    Comment actions Permalink
  • Jeff Lamb

    Hi Stephen

    I would spend the time generating a PS script if i needed to do this more than once every couple months :-)
    The image has the dns suffix in place so that isnt needed on a per machine basis

    All that is needed post image is to add the machine account and one entry.

    JC

    0
    Comment actions Permalink

Please sign in to leave a comment.