Non-Domain for the millionth time...

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

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.  

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 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.

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?

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!

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.

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

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

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.

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

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

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.

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

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.