anyweb

whether it responds to ping or not doesn't really matter, what does matter is whether you can reach your pki.mydomain.com though, and clearly if it's not working for you, then your port forwarding via Vyos must be configured incorrectly, double check the settings and verify that it's forwarding port 80 to the local ip address of your webserver hosting the crl you can test this by using https://canyouseeme.org/ to verify if your port 80 is indeed open when testing browsing to the webserver url, you must disable WIFI on your phone and use your 3g connection

what is not working exactly ? be specific, I've gone through this lab multiple times and it works every single time.

@dreddric it's done now see >

Introduction Update: March 2022. This is now resolved natively in ConfigMgr 2203 or later, please review this post for more info. NOTE: If you are using ConfigMgr 2103 or later do NOT use the Invoke-MbamClientDeployment.ps1 Powershell script as it will cause serious problems with your site. Read the following and scroll down for more info. see https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/mbam-v25/how-to-enable-bitlocker-by-using-mbam-as-part-of-a-windows-deploymentmbam-25). I've had a lot of questions recently about people wanting to use the new BitLocker Management capabilities in Configuration Manager, and to make use of those abilities during OSD (Operating System Deployment). First things we need to keep in mind is that the BitLocker Management capabilities change quite a bit depending on the version of ConfigMgr you are using, the newer version it is, the more feature rich. With ConfigMgr 1910, the abilities are minimal and therefore you'll have to have manual steps to make up for it in the task sequence. A lot has changed since the early release of Bitlocker Management so in this blog post I will assume you are using either CM1910, CM2002 or CM2006. So what is our overall goal here? It's to better understand what the different versions of Configuration Manager (with BitLocker Management enabled and configured as per my previous guides) and to be able deploy an operating system (Windows 10 version 1909 or later) to a computer and have it secured from the outset with BitLocker, and to have BitLocker configured with the same encryption algorithm we defined in our BitLocker Management policy and for the recovery key information to be stored in ConfigMgr's database. Note: As the ConfigMgr agent is in provisioning mode during Operating System Deployment (OSD), it cannot process policy, therefore even if you add the computer to a collection targeted with BitLocker Management policy during OSD, it will not apply that policy until after the task sequence has successfully completed operations. Deploying a computer with default BitLocker steps using CM1910 or CM2002 In ConfigMgr if you create a standard Install operating system task sequence with BitLocker included, even with BitLocker Management enabled, it will add a few BitLocker Specific steps namely Disable BitLocker (Capture USMT state phase) PreProvision BitLocker Enable BitLocker These steps alone can enable a default configuration of Bitlocker but it may not be what you want, for example, the encryption algorithm will most likely not match your policy setting and will instead use the default value of XTS-AES 128 shown below. In addition, the conversion listed above is Used Space Only Encrypted, you can change that to Full Disk Encryption if that's what you prefer For more info on using the FDE options in the steps see the following blog post. https://www.niallbrady.com/2020/02/25/full-disk-encryption-a-closer-look-on-real-hardware/ If you leave everything in the default task sequence as default the end result will be a Bitlocker encrypted OS volume with XTS-AES128 using Used Space Only as shown here. The computer will not have any MDOP agent installed (unless you target it somehow) and will not have any BitLocker Management policy deployed (unless again, you somehow target it with that policy. Changing the default Encryption Algorithm To change the encryption algorithm in an OSD task sequence in Configuration Manager 1910 or 2002 you'll need to add steps (before the Pre Provision BitLocker step) to the task sequence to force that encryption algorithm. The possible settings are listed below as registry keys, the REG_DWORD value 7 below will force it to use XTS-256 AES which is recommended. cmd /c reg.exe add HKLM\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethod /t REG_DWORD /d 7 /f as shown here. The values you can use are listed below: Value 3, AES_128: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an AES key size of 128 bits. Value 4, AES_256: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an AES key size of 256 bits. Value 6, XTS_AES128: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an XTS-AES key size of 128 bits. – This is the default of Windows PE 10.0.586.0 (1511 Release) Value 7, XTS_AES256: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an XTS-AES key size of 256 bits. Setting these registry keys is not necessary in ConfigMgr version 2006 or later as you can explicitly set the encryption method in the Pre-provision BitLocker step as shown here. Ok now that we know how to force the algorithm, let's redeploy the computer to see the result. So that was successful, but still there is no MDOP client agent and no BitLocker Management policy. Adding the MDOP agent To add the MDOP agent is simple enough as the MSI file we need is included with the files installed when you install the Configuration Manager client agent, and located in C:\Windows\CCM. To install it during a task sequence, simply create a Run Command Line step after the Setup Windows and ConfigMgr step but before the Enable BitLocker step as shown below. So, now that we've configured the Encryption Algorithm and have added the MDOP Agent, let's redeploy our computer to see what happens. The end result, we have the right encryption algorithm settings, and the MDOP agent is installed, but there is still no BitLocker Management policy applied. Meaning that the MDOP agent won't know what to do with itself and therefore no new keys will be stored in ConfigMgr's database from this computer (until it get's BitLocker Management policy) as you can see below, note today is 2020/8/14 and the last key added in this lab was a month ago exactly. So what is our next option ? Manually forcing the BitLocker Management policy To 'tell' the MDOP agent where to send it's gathered data (keys, compliance and more), you can download some scripts from this link. You will use those files to create a package within ConfigMgr, and later add the package as another step in the task sequence. This can manually force the MDOP agent into reporting the data to your respective recovery service. Once done, distribute the package and add a new Run PowerShell Script step to the task sequence. Fill in the following details Package: MDOP Scripts Script name: "Invoke-MBamClientDeployment.ps1" Parameters: -RecoveryServiceEndpoint "https://<RECOVERYSERVICE>/SMS_MP_MBAM/CoreService.svc" -EncryptionMethod "XTSAES256" -EncryptAndEscrowDataVolume -IgnoreEscrowOwnerAuthFailure -IgnoreReportStatusFailure -WaitForEncryptionToComplete Replace <RECOVERYSERVICE> with the site hosting your configured BitLocker Management recovery service eg: https://CM01.windowsnoob.lab.local Note: This step requires the MDOP agent is installed, so make sure you added it in the previous step. Note: Once done, disable the built in Enable BitLocker step, however, keep in mind that doing so will stop the BitLocker recovery data from being stored in Active Directory. If you want the recovery data in AD, then don't disable this step. Ok, now that that's done, let's redeploy our computer again to see what happens. This time, in addition to our Encryption Algorithm being set, the recovery key is stored in ConfigMgr's database. So now the recovery information is stored in the database but still the configmgr client agent doesn't have any policy applied (unless you add that computer to a collection with the policy deployed to it). Summary To summarize, you've created manual steps in the task sequence to set the desired encryption algorithm settings, you've created a package and installed the MDOP agent and used a PowerShell script to store the recovery key information in ConfigMgr's database. You would however still need to add the deployed computer to a collection where BitLocker Management policy is deployed if you want to report on the compliance of your deployed computers. In other words, there is no real native support for BitLocker Management configured policy within an OSD task sequence currently, instead, you must manually specify those configured settings within your task sequence if you want your devices encrypted with the same settings as your configured policy. Lastly, if you are using CM2006 or later, things are a little bit easier and you no longer have to manually set the registry keys for encryption algorithim, instead in both the PreProvision BitLocker step and Enable BitLocker step you have a new drop down which you can use to set those values.

Introduction I was busy putting together another BitLocker Management OSD related blog post in one of my PKI enabled ConfigMgr labs (#11) when I noticed that PXE boot no longer worked. The virtual machine would attempt to PXE boot for a while and then time out and boot straight into the operating system. PXE boot worked just fine the day before and I was nearly done with my blog post, so what was the issue ? A quick look at the smspxe.log file revealed some details within a sea of red. The most interesting line was this one, it’s referring to WINHTTP (that would be IIS) and CERT_DATE_INVALID ! [TSMESSAGING] : WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID is set Digging deeper So I guessed I had an expired certificate but a quick glance as pkiview.msc on the IssuingCA server, didn’t reveal any issues. Next, I checked certsrv.msc on the IssuingCA to list expired certificates, and I sorted by name so I could easily find my IIS certificate. According to this, it expired yesterday (today is 2020/8/16). And there you have it, the SCCM IIS Certificate which I deployed 2 years ago, with a lifetime of 2 years is now expired. To confirm this, I launched Internet Information Services (IIS) Manager on the ConfigMgr primary server (CM01), and selected Default Web Site, then selected Bindings. And then I clicked on https and then clicked on View. and there’s the proof, This certificate has expired or is not yet valid It expired yesterday right in the middle of another blog post I was putting together, and that caused me to lose focus as I had to figure out this new issue, so one day led to another.. and inevitable delays. So now we know what the problem is, how do we fix it. Requesting a new certificate Note: This environment is one of my labs, so your setup will differ. Use these steps as a guide to fixing your broken production environment On the ConfigMgr primary server hosting IIS where you verified that the certificate had expired, start certlm.msc. We will use this to request a new certificate to replace the old expired certificate. In Personal, Certificates, right click and choose All Tasks and then Request New Certificate. Click Next at the Before you begin screen, and verify that Active Directory Enrollment Policy is selected before clicking Next. Select the SCCM IIS Certificate from those listed. You’ll notice that for the SCCM IIS Certificate, more information is required to enroll, Click on the More information is required to enroll for this certificate message to enter this info. For Alternative Name, choose the DNS option and then click on Add to add both the hostname and the fully qualified domain name of your SCCM server (CM01 and CM01.windowsnoob.lab.local). Next Click on General, and give this cert a friendly name so we can distinguish it in IIS later when we bind it. click OK, then click Enroll. Click Finish when done. You can now see the new certificate listed, double click on it to bring up it’s details, as you can see it’s now got an additional 2 years before expiry and it has the new Friendly Name. Import the new certificate into IIS On the SCCM server (CM01), start Internet Information Services (IIS) Manager, expand Sites so that you can see the Default Web Site and the WSUS Administration websites listed. Select the Default Web Site, this web site is where the management point, distribution point and other SCCM roles such as Application Catalog can be found (if they are installed). Right click on the Default Web Site and choose Edit Bindings from the options available. In the window that appears, select the https section (port 443) and choose Edit. In the screen that appears, change the dropdown for certificate from SCCM IIS Certificate (the expired one) to the newly released certificate called Endpoint Manager Certificate. Click OK and then click Close. Test the changes Now that you’ve fixed the problem, PXE boot a computer again to verify the changes and as we can see, the SMSPXE.log is happy and PXE boot is working again, RESULT !

glad to hear it, and thank you for the thanks

not yet, maybe this weekend or tonight, i'll spin up the lab again, actually i've started writing a blogpost now and hopefully it'll be finished tonight.

so you did an inplace upgrade of the operating system, did you also restart all the SMS related services after the upgrade ? including post upgrade tasks such as those mentioned here ? https://byteben.com/bb/sccm-site-server-in-place-upgrade-from-windows-server-2012-r2-to-windows-server-2019/#4

I haven't tested constrained language mode with this, but according to this blog post paragraph, you can do as follows let me know how you get on

Introduction Microsoft released TP2008 yesterday, more details here, but I was busy building my deck so I didn’t blog anything, but I did the upgrade and waited until today to see what’s new. And as usual, it’s a list of loads of new additional features. So what is new and exciting in this technical preview release of ConfigMgr? Collection query preview When editing queries for collections you can now preview the results real time. So let’s try it. I created a new collection and added a query for Windows 10 version 1903. You can now click on the green triangle to see the results of your query. and it displays like so… Cool stuff ! This means you can test your queries while creating a collection. Analyze SetupDiag errors for feature updates With the release of Windows 10, version 2004, the SetupDiag diagnostic tool is included with Windows Setup (previously you’d have to download it if you wanted to review it’s data). If there’s an issue with the upgrade, SetupDiag automatically runs to determine the cause of the failure. Configuration Manager now gathers and summarizes SetupDiag results from feature update deployments with Windows 10 servicing. To see these errors, check the Windows 10 servicing dashboard in Software Library. Mine is currently blank, I guess I need to start upgrading existing devices to 2004 and see what data it gathers. Collection evaluation view Microsoft has integrated the functionality of Collection Evaluation Viewer into the Configuration Manager console. This change provides administrators a central location to view and troubleshoot the collection evaluation process. The console now displays the following information: Historic and live information for full and incremental collection evaluations The evaluation queue status The time for collection evaluations to complete Which collections are currently being evaluated The estimated time that a collection evaluation will start and complete I’m not sure why mine has no data yet but i’ll see if I can get it to populate. Delete Aged Collected Diagnostic Files task You now have a new maintenance task available for cleaning up collected diagnostic files. Delete Aged Collected Diagnostic Files uses a default value of 14 days when looking for diagnostic files to clean up and doesn’t affect regular collected files. The new maintenance task is enabled by default. See task sequence size in the console This is interesting, and will show you the size of your task sequence. It’s a new column which is enabled by default, I’m not sure why all my task sequences are reporting 0KB but I’ve asked Microsoft PG for comment. So it turns out if you edit any task sequence (add a comment in the description or whatever) then Apply the changes then it will display the task sequence size (thanks to Adam Gross for the tip). Monitor scenario health Configuration Manager is complicated to troubleshoot. It’s especially complex to understand system latency and the backlog between components. Cloud service-attached features increase that complexity. You can now use Configuration Manager to monitor the health of end-to-end scenarios. It simulates activities to expose performance metrics and failure points. These synthetic activities are similar to methods that Microsoft uses to monitor some components in its cloud services. Use this additional data to better understand timeframes for activities. If failures occur, it can help focus your investigation. There are more features, but these were the one’s I looked at, as always Microsoft is innovating ! cheers niall

Hi @Mayur ok then you are contradicting what you said earlier, oh well, if it is indeed returning the correct ip address then that means godaddy is working, the 'request timed out' could be because of your firewall solution blocking ping or windows firewall itself, and it's not the end of the world, you now need to verify that you can browse the IIS welcome page on your url by browsing on a phone (not connected to wifi, use 3g instead..) to the http://pki.windows-noob.com obviously use your own url for this testing. if that doesn't work, then your vyos firewall is not routing port 80 correctly to the local ip address of the webserver cheers Niall.

then you may have issues with godaddy, because the ip address (in yellow) is returned from the DNS provider, if it returns no ip address then it is not resolving the url to an ip. use https://dnschecker.org/ to verify what your configured url is telling you

so are you saying the you don't see any ip address like I have higlighted in yellow below ?

you are not answering my question, if you ping your pki.yourdomain.com it should return the IP address you configured in godaddy, does it ? and does that ip address also correspond to the internet ip address which www.whatismyipaddress.com revealed on the webserver ?

after you ping the url pki.whatever.com it should list the correct INTERNET based ip address which you are sharing internet from in your pki lab, does it ?

well it could be your firewall solution that's blocking it, i don't know, I use smoothwall and it works just fine. when you ping the url, it should return the correct ip address, does it ?

I am not able to ping nor browse from mobile/laptop/desktop. what do you mean you are not able to ping ? what ip address does it resolve to ?

hi Muray, this does not look like my setup, but then again DNS providers have different views of the same thing, obviously you need to use your own domain name (eg: pki.mydomain.com) and your own internet ip address once you've made the change in your DNS provider, you can test if it works by pinging the url and see what ip address it returns, or try and browse the url from your phone (external network) for example you can ping or browse http://pki.windows-noob.com it should respond as the lab is online now.

hi Muyar, the 192.168.x.x address at godaddy will never work, as that's a local lab ip range, it must instead point to the actual internet ip address you have in your lab (use www.whatismyipaddress.com to find out)

ok, if you really want to use the capture method (and i recommend against it), then you can capture the wim of the OS partition only, and deploy that in your deploy operating system task sequence https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/capture-and-apply-windows-system-and-recovery-partitions but really, don't do that, instead, use default Operating System wim files from microsoft (they are updated monthly now), and add the customizations in your task sequence instead.

Hi Muyar, thanks, so you configured the DNS cname in your DNS provider but it's not redirecting to your webserver, is that correct ? did you also configure smoothwall ?

Introduction I received a brand new HP Laptop (HP EliteBook 830 G6) to verify our current Autopilot setup, and I went through OOBE. All seemed well and I was curious about the version of Windows shipped so I ran WinVer. The following screen appeared. Notice how the registered owner and registered organization fields are automatically populated with HP's default settings, this was a Windows Autopilot enrolled HP delivered with HP's business clean image (no bloatware). The following registry key reveals where those values are set. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion if the following REG_SZ keys are missing: RegisteredOrganization RegisteredOwner You'd see the following instead. So now that I knew why I was seeing those values I decided to fix it. Step 1 - Add a PowerShell script to Endpoint Manager In Microsoft Endpoint Manager select Devices and then select Scripts as shown here (alternatively, choose Devices, Windows, PowerShell Scripts...) Click on Add and select Windows 10 as the operating system. Fill in the Name of the script and a description, note that the Name does not have to match the actual name of the script. Note: you must be a logged in member of windows-noob.com to download this script. Next, point it to the PowerShell script which you can download here and select to Run this script using the logged on credentials. Next select the Groups you want to assign it to, I selected my Windows 10 Autopilot DEVICES group Step 2. Test an Autopilot device Start OOBE (out of box experience) on an Autopilot enrolled device. move through the screens and you'll have to enter your credentials at the welcome to your Tenant name screen after signing in successfully the Enrollment Status Page will appear (if configured to do so) Step 3. Verify changes If everything went according to plan, after a while Windows Autopilot will be completed and you'll be logged on to the desktop, you can now verify the changes by typing WinVer. Troubleshooting If things didn't go as planned take a look at the IntuneManagementExtension.log with CMTrace. It's found in the C:\ProgramData\Microsoft\IntuneManagementExtention\Logs folder and confirm that the script ran successfully and that it ran in User context (user was a local admin in this case). If you need to run it as SYSTEM then change the variable for RegisteredOwner in the script to something else. job done ! Downloads Here's the PowerShell script used above ConfigureRegistered_User_Org.ps1

hi, which Powershell script are you using exactly ? and have you verified that the computer is in a collection with the policy targeted to it during OSD ?

Why oh why do this, please explain ? most people nowadays deploy a clean WIM and add apps/settings during the task sequence or use Windows Autopilot

SysAdmin Day has arrived, and with it, gratitude for all the unsung heroes that 2020 has needed. Your hard work has made it possible for all of us to keep going, despite all challenges thrown our way. Now it is Altaro’s turn to thank YOU. If you are an Office 365, Hyper-V or VMware user, celebrate with Altaro. Just sign up for a 30-day free trial of either Altaro VM Backup or Altaro Office 365 Backup – it&#39;s your choice! What can you win? Receive a €/£/$20 Amazon voucher when you use your trial of Altaro Office 365 Backup or AltaroVM Backup Get the chance to also win one of their Grand Prizes by sharing your greatest 2020 victory with Altaro in an up to 60-seconds video. What are you waiting for? Sign up now!