You asked why, so... We're very federated here, one of the ways I keep department resources separate from each other in SCCM is by discovering the OU they are in then building an SCCM "environment" for that department. I give each department an "All <dept> Systems" "top-level" collection built on an OU query, so when the admin in <dept> opens the SCCM console, all he sees is that top level collection with all the objects that has his OU in the query, and can then build other collections with that as the limiting collection.
On Windows if a computer is on and the SCCM client is alive and sending data, then it's also updating its domain password and stays discovered with the current OU info to keep it in its department, so admins can move it around and it still stay in their scope. (I currently have 'Only discover computers that have updated their computer account password in a given period of time' checked.) On linux though, it doesn't regularly change its password on AD, so having that box checked will mean that those objects will fall out of discovery in that amount of time, meaning that those objects will have active SCCM clients, but could have outdated discovered OU data in the future, which can affect which collections it's in if they are based on OU path query, etc. It wasn't a big deal before we were trying to put Linux on AD. I had written a powershell script to change the password on our 'dummy' linux objects to keep them discoverable for the OU info, but once I got SSSD working on linux, that script broke SSSD because the password on the domain object changed and wasn't what the linux box knew anymore, so broke AD auth. Why do I care about excluding computers from discovery? Because we are so federated, I don't control what departments do with their AD computer objects, or not, and would love to keep the number of discovered objects manageable in SCCM if I can, since I can't control that in AD. So if using the password change age doesn't work for everything anymore, the other option is to only discover computers that have logged on to a domain in a given period of time. I'm trying to figure out if I have to force it to logon through some process, or if SSSD will update the lastlogontimestamp to keep them discoverable, or not, even when no one is logged on for extended periods. Time will tell I guess. I'll just stay logged off my test linux machine and wait 3 weeks and see what happens with the attribute on AD. If it updates, I'll switch to using that instead of password updates, if it doesn't, I'll have to come up with something. I just wondered if anybody knew, to save me the two to three weeks I'd have to wait to find out, then try to come up with something if I needed to, since lastlogontimestamp is calculated with a 14 day +5% drift from the last logon. Logon events for people and Windows is easy enough, I'm just less sure about RHEL attached to AD with SSSD. From: listsadmin@lists.myitforum.com [mailto:listsadmin@lists.myitforum.com] On Behalf Of Jason Sandys Sent: Saturday, October 10, 2015 4:11 PM To: ms...@lists.myitforum.com Subject: [mssms] RE: computer account lastlogontimstamp Why would they age of ConfigMgr? If they have the ConfigMgr agent on them, then they will successfully send heartbeat DDRs as well as policy requests and hardware inventory. AD discovery is only really significant if the system doesn't have an agent on it as far any timestamps go. J From: listsadmin@lists.myitforum.com<mailto:listsadmin@lists.myitforum.com> [mailto:listsadmin@lists.myitforum.com] On Behalf Of Mote, Todd Sent: Friday, October 9, 2015 4:00 PM To: ms...@lists.myitforum.com<mailto:ms...@lists.myitforum.com> Subject: [mssms] RE: computer account lastlogontimstamp I get all that, but I'm trying to figure out if I might need to make a cron job to have something happen to keep it fresh. I worry that if we have a linux machine on AD and in SCCM and it patches on a maintenance window, there may be a length of time that no actual AD user logs into it. I don't want them to age out of SCCM. At the same time, I don't want to turn off that feature in discovery either. So I was trying to find something I could do on the linux side to poke that attribute... From: listsadmin@lists.myitforum.com<mailto:listsadmin@lists.myitforum.com> [mailto:listsadmin@lists.myitforum.com] On Behalf Of christopher.catl...@us.sogeti.com<mailto:christopher.catl...@us.sogeti.com> Sent: Friday, October 9, 2015 3:20 PM To: ms...@lists.myitforum.com<mailto:ms...@lists.myitforum.com> Subject: [mssms] RE: computer account lastlogontimstamp The lastLogontimeStamp attribute is not updated every time a user or computer logs on to the domain. The decision to update the value is based on the current date minus the value of the (ms-DS-Logon-Time-Sync-Interval attribute minus a random percentage of 5). If the result is equal to or greater than lastLogontimeStamp the attribute is updated. There are no special considerations for replication of lastLogontimeStamp. If the attribute is updated it is replicated like any other attribute update. ________________________________ From: listsadmin@lists.myitforum.com<mailto:listsadmin@lists.myitforum.com> [listsadmin@lists.myitforum.com] on behalf of Krueger, Jeff [jkrue...@hfhs.org] Sent: Friday, October 09, 2015 4:06 PM To: ms...@lists.myitforum.com<mailto:ms...@lists.myitforum.com> Subject: [mssms] RE: computer account lastlogontimstamp Don't'have any specific experience with linux machines bound to AD, but the last LastLogonTimestamp is updated throughout the AD hierarchy for machines on a random interval that is between 9-14 day (if I remember correctly) by default. When a machine logs on to AD there is a current time on the DC that machine authenticated with but that doesn't get synced each time a machine logs on. So... if you can look for the DC that machine is logging on to and see if the date/time is current, then you can know that the LastLogonTimeStamp attributed will be updated some time within 9-14 days after the current value in the attribute. From: listsadmin@lists.myitforum.com<mailto:listsadmin@lists.myitforum.com> [mailto:listsadmin@lists.myitforum.com] On Behalf Of Mote, Todd Sent: Friday, October 9, 2015 2:47 PM To: ms...@lists.myitforum.com<mailto:ms...@lists.myitforum.com> Subject: [mssms] computer account lastlogontimstamp Anybody know what will trigger a change in a computer account's last logon timestamp? I'm trying to figure out how to keep my linux machines joined to AD via SSSD with the SCCM client on them, discovered. They don't change their account password like windows machines do, so I'm trying to figure out how to make sure last logon timestamp works from linux. So live machines don't get culled by discovery. Anybody know? Todd Todd Mote, MCP, MCSA+Messaging, MCSE | mo...@austin.utexas.edu<mailto:mo...@austin.utexas.edu> Enterprise Systems Management | Information Technology Services | The University of Texas at Austin ________________________________ CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy & Security page on www.henryford.com<http://www.henryford.com> for more detailed information as well as information concerning MyChart, our new patient portal. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.
