anyweb

That used to be the way it was when SCCM had a hybrid mode, that has been depreciated and now, it uses cloud attach. Please see our series of blog posts on the subject here. Parts 2 and 3 will help you setup a CMG which can also function as a CDP (cloud distribution point).

they are there, try again, only logged on members of windows-noob.com can download scripts

so are you converting the computer from legacy to UEFI and also converting the file system > if not it won't work

IIS doesn't host the recovery keys, they are stored in the ConfigMgr database. The recovery service runs on IIS and that's probably what you are thinking about. The following guides should cover everything you need including HTTPS (pki) which is listed at the bottom of the blog post. If you don't want to go all https (and i'd recommend you do...) then simply add the HTTPS cert to IIS as explained in https://www.niallbrady.com/2019/11/13/want-to-learn-about-the-new-bitlocker-management-in-microsoft-endpoint-manager-configuration-manager/ why are you testing with ConfigMgr 2002, 2010 is out already cheers niall

Introduction In a previous blog post I explained how you could use the SendGrid resource in Azure to send emails, and with a PowerShell script create an Intune app to give end users additional options when resetting their Windows Autopilot provisioned pc. This app would gather the Autopilot diagnostic logs (and other relevant logs) and send an email to your support inbox prior to resetting the pc. I've now updated the code quite a few times with the following changes. modified text boxes to 'read' better modified warnings to make it clear when a device might become unbootable added visual clues (traffic lights) to show which method is recommended changed the default method to Wipe added code to check for missing WindowsRE environment and to attempt to repair it if missing modified reg keys so you can reinstall from the company portal if you click cancel bug fixes Well that's it, so let's take a look at some of the changes. When it launches, by default the Wipe method is highlighted with a Green traffic light. This is the recommended Windows reset option for most users. the Refresh option is shown as follows... and the Secure Wipe option is shown with a red stop light, this visual clue should hopefully get the users to think before continuing with this method... If the user hovers over a method they'll get tooltips about what it does And if they decide to continue they'll get more info about the possible choice made (it's a dynamic message) If the user proceeds with the reset then the Windows Autopilot (and other related logs) are gathered, zipped up and emailed to your inbox, and other actions can be taken within the reset-windows.ps1 script, such as a payload of your choice (hint: remove device from an azure ad group) before finally resetting Windows using the method you specified. that's it ! please test this new release and give me your feedback for instructions to set this up, use the new scripts in this blog post but see how here. Downloads You can download the new solution here: resest-windows_ver_07_windowsnoob.zip cheers niall

the best thing for you to do for now is to create a lab environment, three or four virtual machines, where you can learn SCCM and understand how it works and practice things before doing them in 'production'. Start with this guide.

i would ignore that for now, your MP is way more important.

start by checking your MP (management point), you need that working before dealing with any other issues MP Control Manager detected MP is not responding to HTTP requests. The http error is 12002. Possible cause: MP service is not started or not responding. Solution: Manually restart the SMS Agent Host service on the MP. Possible cause: IIS service is not responding. Solution: Manually restart the W3SVC service on the MP. log file retetion is explained here https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/about-log-files

take a look at this for some clues

no problem ! glad to hear you got it resolved

ok @EngiNerd I got the files from a fellow MVP, please confirm that it solves your problem (check your pm)

ok that sounds like it's in HTTP mode. If you check the site component status, how does it look are there any major issues there? On the clients, what do you see in this screen (a screenshot would help)

I will check with Microsoft, but in the mean time you may have to raise a case with Microsoft Premier support

is this a http or https (pki) environment ?

hi, what version of ConfigMgr and how many clients are connected to it ? are the clients the same version as the primary site ?

probably the easiest way to do this would be to use a script and to create a package/program to run it, a task sequence could also work but requires more effort on the client side and would be more visible to the end user, I'd suggest coding a script in Powershell or whatever language you feel ok with and package that up, from memory though the error code 1 usually means it can't find the script or incorrect function

Introduction I've touched on this subject before where I used http triggers to add devices or users to an Azure AD group after Windows Autopilot was completed, however that solution did not check the compliance of the device prior to adding it to that Azure AD group, and you may have assigned profiles to that Azure AD group which depend on a compliant state. After Windows Autopilot is complete the compliance state of a device a can vary between any of the following states depending on various factors (usually time, and the number of compliance policies deployed and how they are configured). Compliant Not Compliant In grace period See ConfigMgr Not Evaluated The initial compliace state can eventually change to a state of compliant can take from a couple of minutes to some hours depending on what compliance policies you have configured. Refer to this docs post for more information about device compliance. Let's imagine you've configured a few compliance policies that check for the status of BitLocker Encryption of a device and Windows Defender anti malware definition updates. If the detected state of those polices don't match the configured policy then the device will be in a state of non compliance or even in something called in grace period. This post should help you solve the problem of adding devices (or users) to an Azure AD group after Windows Autopilot is complete, but only when they are in a state of Compliance that you want, in this case, Compliant. However it is complex, so before you start, please familiarize yourself with the following 2 posts, in fact I'd suggest you get the below working before proceeding as it will prepare you for this solution nicely. Adding devices to an Azure AD group after Windows Autopilot is complete - part 1 Adding devices to an Azure AD group after Windows Autopilot is complete - part 2 Understanding the solution So how does this all work ? The solution is actually made up of several scripts (and a trigger) listed below. CheckCompliance_CreateScheduledTask.ps1 The CheckCompliance_CreateScheduledTask.ps1 script will exit without doing anything if it detects that Autopilot was completed more than 48 hours ago. This script creates a scheduled task called CheckCompliance to run every 15 minutes. The scheduled task runs a CheckCompliance.vbs script which in turn runs a CheckCompliance.ps1 powershell script. Note: Both the CheckCompliance.vbs and CheckCompliance.ps1 scripts are embedded (base64 encoded) within the CheckCompliance_CreateScheduledTask.ps1 script. CheckCompliance.vbs This script is used to launch CheckCompliance.ps1 in hidden mode. CheckCompliance.ps1 This script does the actual call to the http trigger and provides the following data dynamically to the trigger: deviceName userName If the device is determined to be compliant it will then extract two more embedded scripts, then it runs AddDeviceToAzureAdGroup.vbs before finally deleting the scheduled task. Note: Both the AddDeviceToAzureAdGroup.vbs and AddDeviceToAzureAdGroup.ps1 scripts are embedded (base64 encoded) within the CheckCompliance.ps1 script. AddDeviceToAzureAdGroup.vbs This script simply runs the AddDeviceToAzureAdGroup.ps1 script in hidden mode. AddDeviceToAzureAdGroup.ps1 This script gathers the deviceId and userName and adds both items to an Azure AD Group. This uses the methodology of this blog post. httptrigger The http trigger itself uses the data delivered to it via the URL to determine compliance based on the data in managed Devices in Intune. How is compliance determined ? On a high level, compliance state is determined via queries in Microsoft Graph which you can test using Microsoft Graph Explorer. You can experiment yourself using a query such as the following. https://graph.microsoft.com/v1.0/users/USERID/managedDevices?$filter=deviceName eq 'ComputerName' Note: To manually test this you'll need to find valid UserID and ComputerName valuesfrom Intune and the results of this query would look something like below. Keep in mind that the UserID is reported as the id in Intune. The Scripted solution does the hard work for you, using Graph Explorer is where you start to test queries before creating the http trigger or back end scripts. Note that you'll need the following permissions granted in Graph Explorer to read this data (in addition to those listed in the previous blog post). Encoding/Decoding base64 scripts Included in the download are PowerShell scripts to encode/decode scripts. You can then edit them to your needs before re-encoding and adding the new base64 string to the appropriate variables. to set everything up please download the following scripts and extract to C:\Temp CheckCompliance.zip Make modifications as necessary to the CheckCompliance.ps1 and AddDeviceToAzureAdGroup.ps1 scripts before re-encoding. Save edited scripts to C:\Temp\CheckCompliance. To encode scripts simply run the relevant script shown below. There are two scripts, one for generating the base64 encoded scripts for the AddDeviceToAzureAdGroup and the other for the CheckCompliance scripts. The newly encoded scripts will be in the Encoded folder. Opening any of those 4 scripts will reveal the Base64 encoding data. Mark it all (Ctrl+a) and Copy it (Ctrl+c). Paste the Base 64 into the corresponding variable in the selected script. So to make changes to the AddDeviceToAzureAdGroup.ps1 script, simply edit the original Powershell script, then encode it, then copy the Base64 code into the corresponding section of the CheckCompliance.ps1 powershell script as shown below. Note that this is only an example, there are 4 embedded scripts in total, you'll get the hang of it soon enough. Decoding is the reverse process, and there are scripts available for you to do that also. Ok by now you should have all the above understood and working, time to deal with the solution. Step 1. Create a new http trigger I will assume you've already created a functionapp as per Step 4 of this blog post. If not, go ahead and create one and then return to this step. Next add the following code to your new http trigger. # Niall Brady 2021/02/15 # checks DEVICE for compliance # needs deviceName and userName to triangulate data # version 0.1 2021/02/15 Initial version, only queried against Azure AD devices # version 0.2 2021/02/17 queries against managedDevices to reveal compliance state more accurately using namespace System.Net # Input bindings are passed in via param block. param($Request, $TriggerMetadata) # Write to the Azure Functions log stream. Write-Host "PowerShell HTTP trigger function processed a request." # Interact with query parameters or the body of the request. $deviceName = $Request.Query.deviceName $userName = $Request.Query.userName if (-not $deviceName) { $deviceName = $Request.Body.deviceName } if (-not $userName) { $userName = $Request.Body.userName } # define the following variables $ApplicationID = "" # this is the id of the app you created in app registrations $TenantDomainName = "" # your tenant name $AccessSecret = "" # this is the secret of the app you create in app registrations # create the body $Body = @{ Grant_Type = "client_credentials" Scope = "https://graph.microsoft.com/.default" client_Id = $ApplicationID Client_Secret = $AccessSecret } # make initial connection to Graph $ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantDomainName/oauth2/v2.0/token" -Method POST -Body $Body # get the token $token = $ConnectGraph.access_token # to improve logging... $triggerName = "Check compliance of a device" $a = Get-Date $body = " `n" $body = $body + "$a Starting the '$triggerName' function...`n" $body = $body + "$a Connected to tenant: $TenantDomainName.`n" # if $deviceName and $userName are provided do stuff.... if ($deviceName -and $userName) { $body = $body + "$a You supplied deviceName: '$deviceName'" + ".`n" $body = $body + "$a You supplied userName: '$userName'" + ".`n" # Start FinduserId $FinduserId = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/users/?`$filter=userPrincipalName eq '$UserName'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value if ($FinduserId.userPrincipalName){ $FinduserId = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/users/?`$filter=userPrincipalName eq '$UserName'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{ $userId=$($_.Id) $body = $body + "$a Found the following userId: $userId"+ ".`n" } } else { Write-Host -ForegroundColor Green "$a UPN not found, FATAL." $body = $body + "$a UPN not found, FATAL." + ".`n" } # end $FinduserId # start FindmanagedDevice $FindmanagedDevice = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/users/$userId/managedDevices?`$filter=deviceName eq '$deviceName'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{ $complianceState=$($_.complianceState ) $body = $body + "$a Found the following complianceState: $complianceState"+ ".`n" } # end FindmanagedDevice # wrap things up... } $body = $body + "$a Exiting Azure function." # Associate values to output bindings by calling 'Push-OutputBinding'. Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{ StatusCode = [HttpStatusCode]::OK Body = $body }) Note. Make sure to add in the missing details (application name, tenant, secret) as per step 8 (no need for a groupID in this one). Step 2. Assign API permissions This httptrigger requires more permissions than previously, namely it must be able to read managedDevices. Below are the permissions I've configured. Step 3. Test the solution in Azure In Azure, paste the following into the Input field of the httptrigger, obviously replace the deviceName and userName fields with valid data from your enterprise. { "deviceName": "AP-791500385977", "userName": "niall@windowsnoob.com" } Click on Run when ready If everything went well the compliance state will be returned. The http trigger is working ! Step 4. Customise the scripts After you've downloaded the scripts it's time to customize them somewhat. In the CheckCompliance_CreateScheduledTask.ps1 change the company name and if you want more time to become compliant, increase (or decrease) the hours from the default value of 48 hours. In the CheckCompliance.ps1 script edit the following lines, make sure to paste in the httptrigger url from your environment in here. In the AddDeviceToAzureAdGroup.ps1 script edit the following variables, use the httptrigger to Add devices (and users) url which you created in this blog post Next, save the changes, re-encode the scripts and add the newly encoded base64 changes to the following scripts. Start with the CheckCompliance.ps1 script, paste in your encoded text here (in between the "") And do the same for the CheckCompliance_CreateScheduledTask Save the changes. Step 5. Deploy the solution In Intune, deploy the CheckCompliance_CreateScheduledTask.ps1 to one or more users as required. That script should contain all the other scripts above embedded if you followed the instructions correctly. Step 6. Verify solution Enroll a new Autopilot device and after logging in for the first time you should see a new Scheduled task appear shortly after you login. There is a corresponding log file for this scheduled task creation stored in the C:\Users\<USERNAME>\AppData\Local\Temp Note: In the screenshot above the time difference has been manually set to 1 hour, even though the install date is a month previous, this is just for testing purposes. This process also extracts the CheckCompliance scripts..into the users Temp folder And when 15 minutes has passed the CheckCompliance powershell script will be triggered by the scheduled task. and in this particular example we can see the computer is not compliant yet, therefore it won't kick off the other actions, which extracts scripts and then runs a script to join Azure AD based on a trigger as per this blog post the scheduled task will keep checking for compliance every 15 minutes (you can edit the script to change that) until the device is compliant, and once it is, the final payload will trigger. Below you can see the device is now reported as Compliant from Intune... and as a result it decodes the AddDeviceToAzureAdGroup scripts and then runs them, finally it deletes the scheduled task and the solution is nearly complete. Those scripts are extracted to the users Temp folder and when run create a AddDeviceToAzureAdGroup.log file. The remaining actions are up to you, you can deploy policy or whatever to that Azure AD group and your device/users will magically end up in this Group and receive policy after Windows Autopilot is complete as long as they have become compliant first. That's it ! job done ?

if you mount the SCCM 2007 SP2 iso you might find what you need, like here for example, i'm not sure if this is enough but it might help

so I found the original media (not the pre-reqs) is still on Microsoft Volume License Service Center, when you try to install it is it giving you errors on all the files or just some ?

ok i looked and sadly they are deleted...

ah I had those files but deleted them recently, i'll dig deeper and see can i find them...

well you can't join a domain if you can't reach the domain, so problem solved, now you need to know why you have no ip, the usual reason is lack of network drivers, so add them to your boot image (if needed) or via the task sequence and things should improve

hi Mark, yes I'm planning on releasing an updated version just as soon as CM2022 is released.... time willing of course. cheers niall <-

did you verify that you have a valid network ip at this point ?

Introduction This is part 4 in a series of guides about cloud attach in Microsoft Endpoint Manager, with the aim of getting you up and running with all things cloud attach. This part will focus on enabling co-management. This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. Paul is 4 times Enterprise Mobility MVP based in the UK and Niall is 10 times Enterprise Mobility MVP based in Sweden. In part 1 we configured Azure AD connect to sync accounts from the on premise infrastructure to the cloud. In part 2, we prepared Azure resources for the Cloud Management Gateway, in part 3 we created the cloud management gateway and verified that everything was running smoothly. In this part we will enable co-management. With co-management, you retain your existing processes for using Configuration Manager to manage PCs in your organization and you gain the additional advantage of being able to transfer workloads to the cloud via Intune. Below you can find all parts in this series. Cloud attach - Endpoint Managers silver lining - part 1 Configuring Azure AD connect Cloud attach - Endpoint Managers silver lining - part 2 Prepare for a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 3 Creating a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 4 Enabling co-management <- you are here Cloud attach - Endpoint Managers silver lining - part 5 Enabling compliance policies workload Cloud attach - Endpoint Managers silver lining - part 6 Enabling conditional access Cloud attach - Endpoint Managers silver lining - part 7 Co-managing Azure AD devices Cloud attach - Endpoint Managers silver lining - part 8 Enabling tenant attach Cloud attach - Endpoint Managers silver lining - part 9 Renewing expiring certificates Cloud attach - Endpoint Managers silver lining - part 10 Using apps with tenant attach Step 1. Create some pilot collections In ConfigMgr, create some collections that we'll use for co-management, a suggestion is shown below. We've created an All co-managed devices collection which will contain all the devices we intend to co-manage. Create one collection for each corresponding co-management workload, and limit those collections to the All co-managed devices collection. The following workloads are currently available: Compliance policies Device configuration Endpoint Protection Resource access policies Client apps Office Click-to-Run apps Windows Update policies Step 2. Configure co-management In the Configuration Manager console, go to the Administration workspace, expand Cloud Services, and select the Co-management node. Right click and choose Configure co-management in the ribbon to open the Co-management Configuration Wizard. The co-management configuration wizard will appear, below screenshot is from ConfigMgr version 2010. On the Subscription page of the wizard, configure the following settings: • The Azure environment to use. For example, the Azure Public Cloud or the Azure US Government Cloud. • Select Sign In. Sign in as an Azure global administrator Note: By default, the option Upload to Microsoft Endpoint Manager admin center is enabled by default, this is part of tenant attach and we will deal with setting up tenant attach in a later blog post, for now, deselect this option for pure co-management. From the drop down select Pilot as we want to selectively target pilot (beta test) our co-managed devices. Browse to the All co-managed devices collection created in step 1. If you select All then all devices will be enabled for Intune Auto Enrollment and become co-managed. The text in the box below is used when deploying the configuration management client to devices already enrolled in Intune via a line of business app. This text is used as a command line parameter to onboard the targeted devices as co-managed. On the Configure workloads screen, keep all the workloads pointing to ConfigMgr for now. We will enroll a client into co-management and then verify the status of that client before and after moving a workload to Pilot. When a workload points to Pilot, you will have to pick a staging collection, use the corresponding collection (from step 1) for that particular workload. You can add one or more devices to that pilot collection in order to test how the workloads behave on those targeted clients. When you move the slider to Intune, this enables that workload for all of your co-managed devices that are present in your All co-managed devices collection. On the staging screen we are not able to select anything since we left all our workloads at ConfigMgr (for now). We will show you how to flip workloads in the next blog post. Click next through the Summary and verify you are happy with the choices before proceeding through to the completion of this wizard. Step 3. Adding devices to the All co-managed collection In this step we will review what happens on a client computer before and after it becomes co-managed. On a computer that is not co-managed, open the Configuration Manager client agent. If you look at the Co-management capabilities property it has a value of 1 as in the screenshot below. This means that the client is capable of co-management but no workloads are configured or targeted to this device. The Co-management property beneath that states Disabled and that is because co-management is not currently enabled on this client. On the same client, open the CoManagementHandler.log in C:\Windows\CCM\Logs and look for the following line. Co-Management is disabled. Expect MDM_ConfigSetting instance to be deleted. The workload=1 matches the co-management capabilities property in the ConfigMgr client agent. On the same device, open a command prompt and type dsregcmd /status This reveals that the client is AzureADjoined = yes. We configured this Azure AD connect to synchronize our devices into Azure in part 1 of this blog series. You can confirm that the device is in Azure AD by checking in https://portal.azure.com under Azure Active Directory devices as per the screenshot below. If you search for the device in the Endpoint Manager console it will not appear at this point as it is currently not enrolled (or managed) in Intune. The screenshot below shows devices in Endpoint In ConfigMgr, add this device to the All co-managed devices collection. Note about licenses. The user that signs on to the device needs to have an Intune license and an Azure Premium license. After triggering machine policy on the client the log file reveals the following. Processing SET for assignment (ScopeId_....) shortly followed by... Successfully queued MDM Auto enrollment And then you'll see the following text: Enrolling device to MDM... Try #1 out of 3 If it succeeds look for the following: MDM enrollment succeeded. If you close and then re-open the ConfigMgr client agent, you should now see that it has changed the Co-management property to Enabled. and if you open the Endpoint Manager console, you'll find your client and it's listed as Managed by with a value of Co-managed as per the screenshot below. and if you look at the device in Azure AD devices the MDM authority will show as System Center Configuration Manager. Related reading Microsoft have produced a bunch of blog posts and videos about Co-management called Cloud connecting with co-management here. You can read a FAQ about co-management here. That's it for this blog post, please join us in the next part where we will look at co-management workloads.