I have a machine where Bitlocker has been turned off, yet Intune still shows the 'Bitlocker required' policy as 'Compliant'.
After it had been turned off, the 'Require Encryption' state changed from 'Compliant' to 'Error', yet the 'Bitlocker Required' state stayed at 'Compliant'.
This was a day ago - it has been rebooted many times since.
It's Windows 10 Pro machine that's Azure AD joined.
Does this policy not show whether Bitlocker is enabled or not?
The 'Require Bitlocker' policy just magically changed to 'Not Compliant'.
I'm guessing it can take quite some time before this changes..
Related
I'm an IT Support Engineer for a company with around 60,000 workstations on our domain. We use AD for most things, but have just begun migrating to VMware's Workspace One.
Recently, we've had a bunch of reports from users that when they manually lock their workstations, it instead logs them out. All apps they had opened close and they need to reopen and login to all of them all over again.
We've checked the GPO and see no issues there, even tried deleting the .pol file and running gpupdate /force but cmd returned an error of unable to update group policy. The bizarre part is that if the machine auto-locks instead of manually locks, it behaves as it should; users log back in and their apps are all still opened.
Anyone have any clue what's going on?
I have noticed that on all these workstations running dsregcmd /status returns that WorkplaceJoined:NO DefaultWamSet:Error (0x80070520) and no details for any connected work accounts despite settings saying they are connected. Not sure if that could be the problem and why it can't get a GP update or if its entirely unrelated.
Attempted fixes:
Deleting .pol and running GPupdate /force to have it recreate the gpo. Update failed in cmd with no error code.
Unenrolling/renrolling in Workspace One.
Proposed next step:
Disconnecting work accounts from settings, clearing the tpm and reinitializing it, reconnecting work accounts and retrying gpupdate /force
I’m going to try to be as thorough as I can, but if you have questions or would like additional tests. I will provide more detail as I can. I have a small number of computers exhibiting intermittent issues when waking from sleep.
Some details:
Bound to Active Directory (although the bind is likely broken when the issue occurs)
OSX - 10.12.3
Machine is Encrypted
Symptoms:
When a user sleeps their machine which enables a locked screen saver, and then attempts to wake the machine, they are unable to log in using their credentials.
If they click on "Switch User" they are then able to log into their account, however, they are not recognized as an admin and can not run sudo commands or unlock system preferences.
It seems, at least with the computer I was able to get hands on with, that they can not authenticate in terminal or system prefs UNLESS they change their network connection to reflect the connection that allowed them to log in. So if they switch user, then connect to wifi, they can not authenticate in sysprefs, but if they turn off wifi, then they are able to authenticate.
When clicking "Switch User" the wi-fi appears to drop, and thus, lets them log in.
Restarting resolves the issue for some users but not others (unverified, going off user input, the machine I restarted did resolve the issue, at least temporarily.)
Generally when I see this issue, the computer seems to have become unbound from Active Directory. Re-binding it appears to resolve the issue temporarily (until AD drops the keychain item again).
The issue was present prior to upgrading to OSX 10.12.
It seems to me like the computer knows to check with AD if the internet is available, but if AD is unreachable or the credentials are not accepted, then it does not know to default to the local cache, unless the internet is turned off completely. I'm not sure what file or files may be involved in that, but I would like to change that file to default to the local cache when internet is connected but AD is unreachable as well as when no internet is present.
This is an issue with the opendirectoryd daemon which bugs when trying to bind with AD.
The raw solution is basically to kill the daemon which will restart and rebind somehow.
There are many ways to automate the kill, a cronjob would work but will require to have the killall command run every minute, which is very dirty.
I am using sleepwatcher (available with homebrew) and set it to launch the kill command everytime the laptop is going out of sleep, which works like a charm.
It's a workaround, but seems Apple doesn't really work on a fix for that issue which is ongoing for years.
Has anyone else encountered this problem:
Every month I apply windows updates to servers using SCCM Software Update Groups. Some servers are considered lower priority so I push the updates as required to the server and expect the updates to install and the server to reboot if necessary during its assigned maintenance window only to find out that the some of the updates are failing. With experience, I have found this is because the system is waiting for a reboot. I would expect that SCCM would know that there is a pending reboot and reboot the server during the maintenance window to finish applying the updates but it does not. It seems as though these are "pending reboots" that SCCM cannot detect.
As a result, this requires manual intervention each month on a dozen or more servers that have to be manually rebooted in the middle of the night so as to not interrupt production.
One of the biggest culprits to this issue is the monthly Malicious Software Removal Tool. It always seems to fail to apply then works after a reboot.
The Computer Restart related setting can be configured in the "Client Setting" node on your console. No matter if you determine to use the Default client setting or the custom client settings, you should make sure that that the value for the restart temporary notification interval and the value for the final countdown interval are shorter in duration than the shortest maintenance window that is applied to the computer (the default values are 90 and 15 mins). This is important for the deployments which require a reboot completed on your clients.
Additionally, you can examine the logs on the client-side as below:
Update deployments related logs: UpdatesDeployment.log, WindowsUpdate.log
Reboot & Maintenance related logs:RebootCoordinator.log,ServiceWindowManager.log
More details about how to track the Update deployment process in ConfigMgr can be found here.
I'm troubleshooting an issue having to do with Think N Do and Windows 7. I set the DCOM settings up as the manufacturer said they need to be. However, computers aren't connecting to each other. I have the computers set to automatically log on to an account at boot. This account is never logged out of.
What I'm finding is when I open a RDP to the computers they suddenly start to communicate with each other. As if it's finally seeing an interactive user. From my understanding of things by having an account automatically log on at boot that account is then the interactive user. Leaving RDP open at all times is not an option. Sometimes the customer forgets and closes out of the RDP session by Xing out of it, they don't log off so the program is still running in the background.
Does anyone have any idea what this could be? It's an issue at a couple customer locations for me.
So I've poked around looking for something like this for a while now, but can't seem to find anything anywhere. In our environment we have a script that disables computers after the last seen AD property on a computer is beyond 15 days. Since we are a mostly laptop environment and people frequently are not connected to the network when they login, the computers once they lock/unlock when eventually do get connected to the domain gets a trust relationship issue because obviously the computer is disabled in AD.
Has anyone seen a script that can run on the local computer that updates the LastLogonDate property in AD of the computer while the user is logged in? I was thinking of just pushing out a scheduled task to all computers that does this every 15 minutes if its even possible. Thanks!