We have a group of devices that are behind on some Windows 10 updates. To make things easier rebooting, I've moved them to our autoboot-enabled policy since the updates require several back to back reboots. We tried to do this over the weekend to lessen the user impact, but we found out this week that a lot of the devices were still getting the preboot authentication screen upon reboot. I've checked the policy, made sure it was assigned to the device, checked in the device through EPO and on the device itself but some of them still receive PBA upon reboot.
This same policy is used on other devices, and all my test devices confirm that the autoboot enabled policy is working. Is there a log on client somewhere that holds this information about when new policies are received?
Solved! Go to Solution.
Most of the time, I check this information in the MfeEpe.log but if it wasn't logging at the default level 3 at the time then we wouldn't see anything about it. Once it is established there typically aren't many messages for the TPM after that in the log.
The more likely choice in your case would be in ePO. In the system properties under the Drive Encryption tab, if you choose "more" it should show "last known TPM autoboot state" as one of the information items.
I know that you had indicated that this is only temporary for the updates. With that, I should note two things. One, any time that automatic booting is used without TPM, the encryption key is stored in plain text so any system should be closely kept because it is open\vulnerable. Secondly though, there is a temporary automatic booting tool that meant for and is typically more fitting for situations like this because you can limit the number of reboots or the amount of time the system is in automatic booting mode.
For troubleshooting this, it will typically take the combination of the McAfee Agent logs and the MDE log, MfeEpe.log. I would start with the MfeEpe.log ensuring that policy enforcement is successfully completing first.
I'm toggling between policies on my test device and trying to pinpoint the steps and at what point it becomes enforced.
-I changed the policy from with PBA to Autoboot enabled.
-Force a check in and task sync through EPO. From the agent monitor I saw the request come through and it finished and closed agent communication. MfeEpe.log did not show any change.
-I rebooted and still received the preboot authentication screen. I signed back in to Windows
-I checked the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\McAfee EndPoint Encryption\MfeEpePc\Status Authentication DWORD and it was still set to (1)
-On the client, I did a Check New Policies/Enforce Policies. After that completed, the DWORD value changed to (0). The only change int he MFeEpe.log were two entries for:WARNING EpoMaLpcLog Service not available
-I rebooted and there was no PBA requirement as expected.
I'm not certain what's actually triggering the client to accept the change in policy.
Perhaps I'm mistaken in my understanding of what you are saying but it sounds like your logging level may be set below the default level in the MfeEpe.log if the only new messages you are seeing are a couple of warnings. What logging configuration does your policy have for MDE logging?
Yes, the default logging level for MDE is level 3 (error, warning and informational). Something to keep in mind though is that since this is applied through policy, and the subject at hand is that policies don't seem to be received or enforced, changing it in the policy may not come through. There is a local option to override the policy setting which would make more sense under the circumstances.
https://kc.mcafee.com/corporate/index?page=content&id=KB67529 discusses a few things. One of which is locally adding LoggingLevelOverride in a specific registry location and defining the logging level there. The article is primarily aimed at debug logging but at this point, I strongly advise against that level and would recommend just setting it to the default level of 3. Then restart the MDE service and attempt to go through a communication session and complete policy enforcement. Then you should have more to go on in the logs. When you are done, you can clear out the LoggingLevelOverride entry (make sure not to delete anything else) if you want to return it to the previous logging level.
Thanks for the information, I toggled that logging level and now do see the policy messages on my working test machine. It seems once the policy enforcement starts, it has to finish on it's own time. No amount of checking in/force syncing seems to speed up that process. When I did a force check in from the EPO after changing policies it marks it in the log as:
EpoState == Start of policy enforcement ==
From there, any manual check it attempt looks like it yielded:
EpoPlugin enforcePolicy: Policy Enforcement is already in progress, skipping this one.
Until, on it's own, about 10 minutes later, these appeared, and from checking the registry setting, the policy did change.
EpoState == End of policy enforcement ==
StatusService Policy enforcement has completed
Now that I know what to look for in the logs, I'll be checking devices that are reporting problems.
Yes, MDE is a bit unique in its policy enforcement compared to other products because of the fact that it has users and their respective token data to maintain. Depending upon what MDE has to do and update, there can be several exchanges before a policy enforcement finishes. For the most part, you can "push" it along a bit at the right times by sending events when one has been created but the MA hasn't forwarded it yet. If it is waiting for an event response, you can potentially speed it up by using the option to collect and send props but that typically shouldn't be necessary and many times is a sign of an issue within the network configuration, firewall, etc.
I have a device, we confirmed the policy is set to our autoboot policy, the Authentication DWORD is set to 0, like other autoboot devices, but it still receives the reboot prompt when rebooted. I grabbed the mfeepe.log file after the preboot screen signed the user into Windows.
In a situation where it appears to have applied an automatic booting policy but is showing the preboot anyway, that brings us to the probability that you are using TPM as a method of protection with automatic booting. If TPM is being used, there are situations where preboot would still be seen. What are your configurations surrounding automatic booting and the usage of TPM? I should note that if automatic booting is to be used, it is recommended to use TPM otherwise the system is left with a significant reduction in the security provided by MDE. Going into this aspect of the subject, we can certainly look at the log file but the log file will contain user names (never passwords). It may be more advisable to open a case and provide it there rather than attaching it for that reason.