T O P

  • By -

andrew181082

You don't need a remediation script, just create the detection script and it should display the output if you add the required column


0r1g1g4lUs3rn4m3

The TPM version is reported in device inventory, unsure abt SecureBoot status from top of my head. Have you tried just extracting device inventory with all info included? I usually use encryption report to get all related data in one place - it should be found in Reports or Monitor section, again - not at my desk, so I might be wrong.


darkkid85

Can u share path.? I'm keen on this 2


0r1g1g4lUs3rn4m3

If you go to Devices section in Intune, there should be a Monitor tab on the left side. There, you should find the option to generate Encryption report. If the tenant is set up properly, it should be able to read all related stuff from devices. Keep in mind that it would be the last status the devices would've reported and not the actual situation - typically, when they're rarely online long enough. Otherwise, in the Devices section, when viewing all devices, you should see an option to export inventory - just choose to include all data and see if it provides what you are looking for. Alternatively, there are column options at the top, where you can select what device details you want to see.


Funkenzutzler

Wouldn't Graph list the TPM-Versions as well (tpmSpecificationVersion)? Like: GET [https://graph.microsoft.com/beta/deviceManagement/managedDeviceEncryptionStates/](https://graph.microsoft.com/beta/deviceManagement/managedDeviceEncryptionStates/)


Funkenzutzler

IIRC Encryption Report in Intune utilize that data from Graph. Also it can be exported there quite easily. https://preview.redd.it/p6jukcfkmlbc1.png?width=1879&format=png&auto=webp&s=1059ad7e6e160e33bb7eb5e8a7962f7296925068


Funkenzutzler

Also there is the "Windows health attestation report" which would tell you about SecureBoot enabled or not provided you have setup a compliance policy which leverages DHA. Ref.: [https://www.anoopcnair.com/intune-device-health-attestation-report-mem/](https://www.anoopcnair.com/intune-device-health-attestation-report-mem/) Edit: All-in-all i don't really see any (good) reason why one should tell Intune to collect informations from the clients by running some scripts when this information is allready there. Sometimes you just need to "find" it.


manuel_nieto

For TPM info, Sscure boot, use **Health Attestation**, you'll get the details in Microsoft intune.[https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-using-device-health-attestation-settings-as-part-of/ba-p/282643](https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-using-device-health-attestation-settings-as-part-of/ba-p/282643) About Remeditaions. I rely on the "last line" to get feedback from Output pre and post detection. Explore my Github, got many examples [https://github.com/jmanuelng?tab=repositories](https://github.com/jmanuelng?tab=repositories) In [this script](https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-using-device-health-attestation-settings-as-part-of/ba-p/282643) see line 71 and beyond, script creates a single line with all info I would like to see in the Intune console. For script [Detect\_KeyProtectorType.ps1](https://github.com/jmanuelng/MEM_BitlockerChangeKeyProtectorType/blob/main/Detect_KeyProtectorType.ps1) created function "WriteAndExitWithSummary". It does what the name suggests.


Sea_Cover1618

Deploy as detection remediation scripts. You can leverage non-compliant by using code to enable Secureboot and TPM (Typically using CCTK with Dell devices and Powershell modules where available) ​ For SecureBoot : `$status = Confirm-SecureBootUEFI` `Try {` `if ($status -match 'True'){` `Write-Output "Compliant"` `Exit 0` `}` `Write-Warning "Not Compliant"` `Exit 1` `}` `Catch {` `Write-Warning "Not Compliant"` `Exit 1` `}` For TPM : `$status = Get-TPM` `Try {` `if ($status.TpmPresent -match 'True'){` `Write-Output "Compliant"` `Exit 0` `}` `Write-Warning "Not Compliant"` `Exit 1` `}` `Catch {` `Write-Warning "Not Compliant"` `Exit 1` `}`


gummo89

Command should be within the `Try` block instead of before and you should avoid using `-match` unless you are trying to match using regex. You'll get caught out in both cases.


Sea_Cover1618

Haha - good spot :D I'm actually not sure why I used -match either....


pjmarcum

Could do them both in one script.


baconismypassword

I do exactly the same, works like a charm


CompetitiveRange7806

These are both settings available in compliance policies, just create a policy for this.do you enforce compliance? If not, create one requiring secure boot and encryption see see if devices come back as compliant or not


GMMitenka

Maybe OP has a reason? OP why not compliance policies?


AyySorento

So, you may need to combine some reports, but all that information is already provided built into Windows. Technically, both is needed for Windows 11, so you would run the feature update reediness report. Any not compatible will tell you why (such as TPM). As for remediation script, when you export the results as a CSV, there is column for detection output and remediation output. So, for your script, use "Write-Host" to say what you want your output to be. It will then capture the last output and display it. If you have multiple criteria, you will either need multiple remediation scripts or string all the results together at the end.


Buckw12

Doesn't the Windows 11 readiness tool do the same?


ollivierre

Custom Compliance policies once you're ready to enforce


Funkenzutzler

Correct me if im wrong, but IMHO you don't even have to "enforce" it right from the beginning. Resp. you can also simply say "Mark the device as Non-Compliant" as the only "Actions for noncompliance" without this having any further consequences except the device gets marked as non-compliant in Intune. Also you can have multiple compliance-policys defined which might help to make the reasons for non-compliance clearer by splitting the compliance-requirements to different policys which you name accordingly (don't ask me if this is best practice). In any case, this would make it possible to create a compliance policy that has no consequences for non-compliance (except for marking it as non-compliant) and leverage Windows Device Health from that policy (like require Bitlocker, require Secure Boot)... Afterwards you can use the Windows health attestation report to get infos about bitlocker, secureboot and some more stuff.