anyweb

ping me a pm, we can do it via Microsoft Teams later this evening, not sure what timezone you are in, but i'm in Sweden/Europe

what version of SCCM are we talking about here ?

would you like me to do a short remote session with you so I can take a look ?

so what DO you see in Reports in SCCM under BitLocker Management ? or is that completely missing ? are you using MBAM or ConfigMgr to manage BitLocker policy ?

take a look at part 7 here, does it help ? https://www.niallbrady.com/2019/11/13/want-to-learn-about-the-new-bitlocker-management-in-microsoft-endpoint-manager-configuration-manager/

@Chazh if you post your smsts*.logs we can take a look at the cause

did you look at part 2 of this blog series ? it's all there

share the logs with me and i'll take a look are you sure you deployed this to the right group ?

great to hear it's working now ?

see here, i explain how this happens (after 10:28...) and how to resolve it (after 13:00)

i'm guessing it's your NIC (network) drivers, what are they shown as in device manager ? have you tried installing the latest drivers+bios version from dell ?

thanks for the update @keywan

i tested it on an already enrolled device (not preprovisioned) and the log file is below, if you want it to detect your devices as preprovisioned then it'll need the whiteglove reg keys created from this solution I've uploaded yet another copy with slight changes above. the files below are what's left after a successful installation and run. win.ap.CreateScheduledTask.SetTimeZone.log Installed_SetTimeZone.txt win.ap.SetTimeZone-GUI.log

here you go, unzip, you'll need to modify the detection method to look at this location as that's another change SetTimeZone scripts - ppfix.zip

for preprovisioning scenarios we have removed the 72 hour check I've an updated version of this script that I can make available if needed

if i get time this weekend i'll see if i can amend it for that...

here's the original code <# Modify Registered user name/org name as shown in Winver adds a reg key, run as logged on user... niall brady 2020/08/06 #> # Add User name and Org name in the "this product is licensed under the Microsoft Software License Terms to: shown in WinVer $UserName = $env:UserName $OrgName = "windows-noob.com" $path = 'HKLM:\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion' $key = try { Get-Item -Path $path -ErrorAction STOP } catch { #New-Item -Path $path -Force } New-ItemProperty -Path $key.PSPath -Name RegisteredOwner -Value $UserName -Force New-ItemProperty -Path $key.PSPath -Name RegisteredOrganization -Value $OrgName -Force change it like so... <# Modify Registered user name/org name as shown in Winver adds a reg key, run as logged on user... niall brady 2020/08/06 #> # Add User name and Org name in the "this product is licensed under the Microsoft Software License Terms to: shown in WinVer $UserName = $env:UserName $OrgName = "windows-noob.com" $path = 'HKLM:\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion' $key = try { Get-Item -Path $path -ErrorAction STOP } catch { #New-Item -Path $path -Force } # when running in SYSTEM context, $UserName will be returned as the Computer # so Change RegisteredOwner to something else, such as your company name $RegisteredOwner = "windows-noob.com" New-ItemProperty -Path $key.PSPath -Name RegisteredOwner -Value $RegisteredOwner -Force New-ItemProperty -Path $key.PSPath -Name RegisteredOrganization -Value $OrgName -Force

That is normal when you deploy it in SYSTEM context, if you want to get something else change the variable for RegisteredOwner in the script to something else.

which version of ConfigMgr is this ? and please take a look at my troubleshooting blogs to give you some ideas

what is the solution you've found @mirshad.kp ? share it with others so that they may learn

I asked Copilot ! and here is what it said, quite interesting In System Center Configuration Manager (SCCM) version 2309, self-signed certificates play a crucial role in securing communication between various components. Let me break it down for you: Signing Certificate: The signing certificate on the client validates that policies sent from the Management Point (MP) were not tampered with. It ensures that the policies received by the client are authentic and haven’t been modified during transmission. Encryption Certificate: The encryption certificate establishes a secure connection between the client and various SCCM components (e.g., MP, Distribution Point). It ensures that data exchanged during communication remains confidential and cannot be intercepted or altered. Protection Mechanism: To compromise the self-signed certificates, an attacker would need to: Phish or perform a Man-in-the-Middle (MitM) attack to intercept the signing certificate. Redirect the client to a malicious SCCM infrastructure. By doing so, they could potentially manipulate policies or gain unauthorized access. Public Certificates: While self-signed certificates are commonly used within SCCM, using a public certificate for the entire SCCM infrastructure is indeed a possibility. However, this approach requires additional configuration and coordination with your organization’s security team. In summary, self-signed certificates protect against spoofing and forging by ensuring policy integrity and establishing secure connections. If you’re considering public certificates, consult with your security team to evaluate the trade-offs and implementation details12.

check your pm

here's the error <![LOG[C:\_SMSTaskSequence\Packages\DIG006E0\Scripts\ZTISCCM.wsf(2, 11) Windows Script Host: The value for the attribute is not valid : language]LOG]!><time="07:22:59.382-120" date="05-24-2024" component="InstallSoftware" context="" type="3" thread="1820" file="runcommandline.cpp:77"> <![LOG[]LOG]!><time="07:22:59.382-120" date="05-24-2024" component="InstallSoftware" context="" type="3" thread="1820" file="runcommandline.cpp:77"> <![LOG[Command line is being logged ('OSDDoNotLogCommand' is not set to 'True')]LOG]!><time="07:22:59.382-120" date="05-24-2024" component="InstallSoftware" context="" type="2" thread="1820" file="runcommandline.cpp:478"> <![LOG[Command line cscript.exe Scripts\ZTISCCM.wsf returned 1] so if you can determine why it's complaining about that you might be able to continue

what does the smsts.log reveal ?

cool, have you seen this > https://www.deploymentresearch.com/fixing-the-mdt-integration-for-configmgr-2403/