ConfigMgr Automatic Deployment Rule Fails with Error Code 1326 if Source WSUS is not a Domain Member
ConfigMgr infrastructure uses a WSUS server in the DMZ which is not a member of the domain, as shown in the figure below:
If you use Automatic Deployment Rule, the sync fails with the following:
- Error code 0X87D20417 in the SCCM Console
- “Failed to download the update from UNC content source. Error = 1326” in ruleengine.log.
Meanwhile, patch metadata is successfully transferred over to ConfigMgr when you sync software updates. Manual patch synchronization by downloading to the Deployment Package is also successful
The top-level ConfigMgr server attempts to access the shared WsusContent folder in your DMZ WSUS using the computer account of your Primary Site Serveror CAS, and fails because it is denied access. On your DMZ WSUS, you cannot grant access to the CAS or Primary Site Server or make them a member of any local group.
You can choose from one of the following options if you intend to use Automatic Deployment Rules
- 1. Copy the contents of \\dmz_wsus\WsusContent to a shared location which is accessible to your top-level ConfigMgr server (CAS or Primary Site Server), and sync the ADR from that location
- Make the DMZ WSUS server a member of the domain and ensure that the top-level Site Server (CAS or Primary Site Server) is a member either of the local Administrators group or the WSUS Administrators group.
Remember, this is only an issue if you use ADR. I haven’t done testing on a normal non user-initiated SCCM update sync. You might want to give me feedback if this error shows up on non user-initiated update sync.
- System Center 2012 R2 Configuration Manager SP1
- Windows Server 2012 R2
jay paloma | 1 may 2016 | singapore
This post is provided “AS-IS” and makes no warranties and confers no rights
“The storage where the virtual hard disk is locaed does not support virtual hard disk sharing” error when creating VMs or moving VMs from one Windows Server 2012 R2 Hyper-V host to another (unclustered). These two machines are managed by System Center Virtual Machine Manager, but I am trying to test VM Migration from the Hyper-V Console because it kept failing in SCVMM.
Stop mucking around with the Hyper-V console when it is be part of SCVMM! Because I turned on the Replication feature (not sure if there is an SCVMM counterpart for this), migration stopped working. So the resolution is disable the Replication feature.
Good old patience and troubleshooting!
I did not find any published resolution to this problem and am already contemplating on rebuilding the lab. Importing VMs also did not work (exporting did work on the two hosts that are a member of SCVMM). I tested importing on a HV host that is not part of SCVMM — it worked! I compared the settings and the difference was that I enabled the two HV servers in SCVMM as Replica Servers. Once I switched off this feature in Hyper-V and tested Migration in HV Console, everything worked.
I am now testing migrating using SCVMM. I will update this post on the results. It’s already 1AM in Singapore and I had a long day.
NEXT DAY UPDATE: successful VM movement using SCVMM. Problem has really been solved. Have a nice day!
jay paloma | 27 apr 2016 | singapore
Information is provided “AS-IS” and makes no warranties and confers no rights.
Here’s my first System Center 202 R2 Configuration Manager automated task using System Center 2012 R2 Orchestrator
- Download the required Integration Pack from this link from the Microsoft website.
- Download the Windows Installer XML (WiX) Toolset (at least v3.5) from this website
- Install the WiX Toolset
- Open the System Center 2012 R2 Orchestrator Deployment Manager and Import the Integration Packs
- Right-click on the Integration Pack and select Deploy IP to Runbook Server or Runbook Designer. This executes the Integration Pack Deployment Wizard
- Open the System Center 2012 R2 Orchestrator Runbook Designer, and in Options select SC 2012 Configuration Manager
- In Connection, click Add, and enter in the information needed to connect to your ConfigMgr. Server should be a Primary Site Server.
- By adding the ConfigMgr Integration Pack, we have new activities pertaining to ConfigMgr available in our Runbook Designer
- To test, let’s now create a new Rubook with only the Create Collection action. Here are the parameters of that Create Collection action
- Run this Runbook. Check in Log History that it succeeded
- Now go to the ConfigMgr console and confirm that the Collection has been created
That’s it! My first ConfigMgr automation with System Center Orchestrator!
jay paloma | 23 apr 2016 | singapore
21 April 2016, Singapore
This blog post is based on current events, I will update this post as I gather updates.
Being a Patriotic Filipino has its downside: by now you have already heard that your personal information is now available and searchable online. And this had to happen during election season, when millions of Overseas Filipino Workers (OFWs) trooped to the Philippine Embassy of their host countries to register as an Absentee Voter or register their biometrics.
There’s really nothing we can do to prevent that data loss, and also nothing we can do to hide our personal information if we are a registered voter. The confidential info available are passport info, local and overseas addresses, email address, etc. So the only thing we could do right now is to further protect ourselves from further compromises to our personal information.
Here are some tips at how a typical OFW can mitigate the damage that will be caused by this data leakage:
- Find out if your personal information has been compromised. As I run the risk of being sued by the relevant Philippine government agency, I will not post the link here. However, Google is your friend.
- Be more extra careful about physically securing your passport.
- Inquire the Philippine Embassy if one could renew one’s passport a little earlier. (I will do this, and will update this site on any development).
- Some OFWs would want their overseas addresses confidential. Since this is no longer the case, if it really matters then it’s time to change address.
More safety tips can be found in this Facebook page.
You installed SQL Server Reporting Services (SSRS) on your Primary Site Server, with the intention to install Reporting Services Point (RSP). In the RSP installation, SCCM fails to find the locally installed SSRS. The drop-down box Reporting Services server instance shows blank when you pull down the drop-down arrow, as shown in the picture
Too high User Account Control (UAC) settings may prevent the RSP installation to detect the locally installed SSRS.
Bring down the User Account Control settings to Never notify and repeat the RSP installation. The installation should succeed.
The information is provided AS-IS with no warranties and confers no rights.
jay paloma | 19 apr 2016 | singapore
2nd Jan 2016, continuing with the doing-nothing-while-on-vacation series.
You can assign access Collection access to Administrative Users. However keep in mind the following:
- If your objective is to ensure limited visibility of collection results, then see to it that you do not grant access to the All Systems collection. You have to have what I call a Top-Level Collection in lieu of the default collections (including All Systems). Ensure that the membership of this Top-Level collection is limited to the objects you want the specific admin to see. Use specific conditions, e.g., OU membership, computer name, etc., to populate. Also keep in mind that the objects are still available in Queries, so if you really need to ensure non-visibility of objects, deal with Queries as well.
- Use this Top-Level collection as the limiting collection for all other collections that you would create. Do not use the All Systems collection because if the user account does not have access to All Systems, then the user account will always see 0 membership. Remember: the user does not have access to the Top Level collection (ergo, 0 members) and you created a collection that limits itself to the All Systems collection (again, 0 members), and you’ll get a collection of 0 members!
So for example you want to create an RBAC role to be able to deploy Applications and Patches to machines from the APAC region:
- Create an APAC Top-Level collection, using All Systems as its limiting collection using OU membership as its criteria.
- Create a second collection of with APAC Top-Level as its limiting collection, and add the additional conditions that it is a ConfigMgr client and it is a workstation OS . Let’s call this APAC Clients
- Create an AD Group APAC Deployment
- Add this group in ConfigMgr Administrative Users, and grant access to the APAC Clients collection. Also assign it the RBAC Role nearest to the deployment role you want, or customize the role further to get the actions you want this role to perform.
Screenshots to follow once I’m back in my lab. Too bad I haven’t installed my ConfigMgr lab in Azure yet at this point in time.
jay paloma | 02 jan 2016 | manila
It’s 2 Jan 2016. Happy New Year 2016! I am currently in vacation in my hometown in Manila (am based in Singapore), and to spend some quality time, I want to write another chapter in the ConfigMgr RBAC series.
In continuation of our series on ConfigMgr RBAC, let’s now take a look at some practical applications of Role Based Access Control in ConfigMgr.
First, division and compartmentalization of Responsibilities. To do this, customize RBAC Roles and assign into different AD Groups but having access to all collections.
Secondly, division and compartmentalization of Objects. To do this, you can use some high-access RBAC Role like Operations Admin but ensure that permissions are assigned only to specific collections, and never assign permissions to the All Systems collection. Do note that as a caveat to this, you cannot assign permissions to any collection that use All Systems as its limiting Collection. Therefore you should create a collection that use All Systems as its collection, then use the newly created collection as a Limiting Collection for the collections that you could assign permissions to.
All Systems –> Limiting Collection of CollectionB –> Limiting Collection of CollectionC <– Assign permissions
Thirdly as hybrid division and compartmentalization of both Objects and Responsibilities. This one is just a combination of both. Something like this setup:
- APAC Admins
- APAC Packagers
- APAC Deployment
- EMEA Admins
- EMEA Packagers
- EMEA Deployment
- HQ Admins
- HQ Packagers
- HQ Deployment
You have 3 regions: APAC, EMEA and HQ and you have 9 sets of admins as shown above. So you have at least 3 sets of collections (APAC, EMEA and HQ) and 3 sets of admins for each region (Admins, Packagers and Deployment), and ensure that APAC Packagers can only package apps intended for APAC, and not EMEA and HQ, and cannot perform any other administrative task or deploy stuff.
If you have this kind of setup, do ensure that you thoroughly check the implementation of RBAC. Also, my experience to this is that since your working collection is 3 layers down (All Systems –> CollectionB –> CollectionC in the above example) do not go cheap on your database server.
As I am right now not in my lab, I cannot have screenshots to show. However I will update this document when I get back after vacation.
jay paloma | 2 jan 2016 | manila