Skip to main content

Interesting question here - What's the best way to scope to a dynamic group of computers not assigned to a site?

University setting. The global level is campus wide and each of our Colleges and/or major departments are grouped into different sites with their IT support contacts.

I would like to grab those computers not assigned to a site and scope an AD profile to them (yes still binding to AD - another discussion for another day) that gets a computer basic functionality (user login) while also notifying us that a computer is improperly configured (bad enrollment, errant site assignment, etc.).

I have groups for each site that contains all the members of that site, i.e. All College of Engineering Computers. Those work and are great containers to get this information.
I then have a group in the none scope set to do the same thing but exclude all these site specific groups. It's a bit process heavy doing it this way but overall accomplishes most of what I want.
However this group (and thus the policy scoped to it) tends to also pick up computers are they are "passing through", that is moving from one site to another.
For example, moving a computer from College of Business to School of Nursing will generate the following: a computer will drop out of College of Business and (expectedly) lose all configuration profiles, get roped into this group, generate an email and try to deploy the basic AD bind, then immediately drop out causing the basic AD bind to report a failure and be put in School of Nursing getting their appropriate profiles and AD bind.

That is causing a lot of failures in the profile log for this policies and a couple of computers left hanging out without any AD bind at all.

If you made it this far, congratulations. Any ideas/help would be appreciated.
I need some method to properly see computers not in a site with no change in that status for the past say hour or 2.

I would like to grab those computers not assigned to a site and scope an AD profile to them

You can create a profile scoped to all machines and just exclude all the site groups. It will only run for machines not in a Site.

moving a computer from College of Business to School of Nursing will generate the following

How are you changing a machine's Site? Flipping it in the web interface, pushing a QuickAdd, re-Reconing, etc?

@tuinte

I would like to grab those computers not assigned to a site and scope an AD profile to them
You can create a profile scoped to all machines and just exclude all the site groups. It will only run for machines not in a Site.

That's exactly what I'm doing.
Here's the problem from my post above.

However this group (and thus the policy scoped to it) tends to also pick up computers are they are "passing through", that is moving from one site to another.

How are you changing a machine's Site? Flipping it in the web interface, pushing a QuickAdd, re-Reconing, etc?

Flipping it in the web interface.

Ok, yeah. So it seems like when you switch a Site for a machine it actually lives as a non-Sited machine for at least a couple of seconds as it switches over and that's triggering the non-Site profile. That's what you mean? (Just wrapping my head around it)

I'd consider doing away with the idea of Siteless computers altogether. Create a Site called Unassigned (or whatever you want to call it), create a smart group for all machines in that (like you have for the other sites) and scoping the AD Profile to all computers in that, so even if a machine passed through Sitelessness it's not triggering anything. You could also do this with an Unassigned building attribute, if you really want Siteless computers. Point being, scope the profile to a positive match instead of an absence.

Make sense? I'm with you for the long haul, let's figure this out!

EDIT: Does the same thing happen if, say, instead of flipping the Site, you pushed a QuickAdd for the Site your moving a machine to? As that would kickoff a re-enroll, I would think MDM would hold off until the enroll is complete (and thus the new Site solidified)

EDIT 2: Yeah, the more I think about this the more it makes sense. Switching the Site first tells MDM the machine isn't in Site A anymore. MDM looks through your scopes and removes anything it has that it now shouldn't and adds whatever is now scoped (kicking off the no-site profile). Only after that, MDM gets news of the updated Site and does the remove/add again with Site B and its scoped policies. In short, switching a Site is two things: removing a site and adding a site, and this kicks off two MDM policy refreshes. I believe my Unassigned Building or Site suggestion would avoid your issue. Lemme know your thoughts.

@tuinte

Ok, yeah. So it seems like when you switch a Site for a machine it actually lives as a non-Sited machine for at least a couple of seconds as it switches over and that's triggering the non-Site profile. That's what you mean? (Just wrapping my head around it)

Yep, that's the issue I'm seeing.

I'd consider doing away with the idea of Siteless computers altogether. Create a Site called Unassigned (or whatever you want to call it), create a smart group for all machines in that (like you have for the other sites) and scoping the AD Profile to all computers in that, so even if a machine passed through Sitelessness it's not triggering anything. You could also do this with an Unassigned building attribute, if you really want Siteless computers. Point being, scope the profile to a positive match instead of an absence.

Yes, that's the idea. I don't want computers in none, but I have to know what computers are there to do something with them. In my case, I would like them to at least be functional while an email/ticket is generated and they can be moved to their proper site. All about getting rid of that downtime, you know.

Re: Edit 1 - Don't know, haven't tried.

Thanks for the interest to help me get to the bottom of this

Hmm...

How is it machines are becoming Siteless? I may be getting hung up on the wrong thing, but in our environment there just isn't a Siteless computer. All enrollment workflows we have include something to put the machine being enrolled into a Site, so we would have to deliberately flip a machine to None to get a Siteless computer.

@tuinte At any given time, we have between 10 and 15 machines that are siteless.
Certainly not a huge deal. It can happen when a self enrollment goes to the wrong site or a tech uses the wrong QuickAdd.

I'm just wanting to properly detect those. Again, using the smart group I can, I just don't want to get the travelers as well.
Just need some sort of delay in the joining of that smart group.

I'm not sure how this helps you in the larger sense of automation, but I thought I'd call out the following post to you or to whomever comes across this thread. It has helped me detect non-sited computers in the past:

mysql script

It happens when we do self enrollment and the person does not select a site from the drop down menu.

In case you have trouble with the link, it was posted by @NightFlight (thank you sir) Here is the code:

select 
    computers.computer_name,
    computers.mac_address,
    computers.last_ip
from
    computers
where
    not exists
    (select 1 from site_objects where site_objects.object_id = computers.computer_id)
order by computers.computer_name asc
Terms & ConditionsCookie settingsAccessibility statement