SCRIPT FOR COPYING A CONFIGMGR ADMINISTRATIVE USER

Standard

Recently at work I found myself in the following situation: We have quite a few SCCM administrative users based on AD groups that we needed to copy/clone. Each of the administrative users has a number of custom roles that are restricted to specific collections and security scopes. Doing it manually would be time-consuming and less than optimal. So I set about to see if someone in the community had a tool or a script.

After my initial inquiries came up short, I started taking a good look at the SCCM PowerShell cmdlets, specifically two: Get-CMAdministrativeUser and New-CMAdministrativeUser.

I started by focusing on the following properties: RoleNames, CategoryNames, and CollectionNames. In our test environment, I pulled them with Get-CMAdministrativeUser, assigned them variables, and tried creating my new user with them. It seemed to work decently enough, until I tried it on a more complex administrative user where each of the security roles is restricted to specific collections and scopes (3rd radio button.) It didn’t work properly in this scenario, so I decided to look elsewhere.

Further research led me to the following helpful blog post by Peter van der Woude: https://www.petervanderwoude.nl/post/verify-the-role-based-administration-model-via-powershell/ Go ahead and read his post. I’ll wait…

OK- I had noticed the Permissions property before but it seemed too easy so I hadn’t started there! Peter does a great job breaking down the WMI underpinnings and explaining the Permissions property. I decided to try getting the permissions property with Get-CMAdministrativeUser and using it with New-CMAdministrativeUser. And that did the trick! Really simple.

You can use Peter’s WMI method from his post above to do all kinds of cool things without the ConfigMgr PowerShell module. I was already most of the way there with my basic little script utilizing the module, so I stuck with the cmdlets. If you have the ConfigMgr module already loaded, and your site drive already mapped, etc. (like if you just launched ISE from your SCCM console) then this is what worked for me. You just need to specify your new user, and your existing user that you’d like to copy:

$NewUser = "DOMAIN\New User"
$ExistingUser = "DOMAIN\Existing User"
$ExistingUserProperties = Get-CMAdministrativeUser -Name $ExistingUser
$Permissions = $ExistingUserProperties.Permissions
New-CMAdministrativeUser -Name $NewUser -Permission $Permissions

If you’re curious, and care to display what the Permissions property returns, you’ll notice a number of entries like this (I sanitized the below example to remove all of our organization/site specific stuff.)

PS <SITE CODE>:\> $Permissions

SmsProviderObjectPath : SMS_APermission
CategoryID            : <CATEGORYID>
CategoryName          : <CATEGORYNAME>
CategoryTypeID        : 29
RoleID                : <ROLEID>
RoleName              : <ROLENAME>

SmsProviderObjectPath : SMS_APermission
CategoryID            : <CATEGORYID>
CategoryName          : <CATEGORYNAME.. Like Limiting Collection>
CategoryTypeID        : 1
RoleID                : <ROLEID>
RoleName              : <ROLENAME>

You’ll notice that it references the WMI class SMS_APermission, like Peter discussed in his blog post. And also from his post, you’ll remember that CategoryType ID 29 references a security scope and CategoryType 1 references a collection.

PXE Booting Issues With New Skylake Chipset Machines

Standard

Recently at my new workplace, we’ve been having issues getting new Lenovo ThinkCentre M700’s to (Legacy) PXE boot. The lights on the NIC actually went out when it tried to PXE boot! (Booting from a boot USB thumb drive worked fine.) Some folks out on the SCCM Subreddit (https://www.reddit.com/r/SCCM/) were having similar issues with various systems based on the new Skylake chipset, like our small Lenovo M700’s.

After someone on the Subreddit stated that they successfully PXE booted using a 100mb unmanaged switch as a workaround, I decided to investigate. I worked with one of our (Cisco) Network Engineers to test changing settings on one of our switch ports. He suggested disabling POE (Power-Over-Ethernet) and his idea was spot on. The new M700 was able to PXE boot after he made the change!

I haven’t seen anything official from Lenovo on the issue, but testing disabling POE on a port is worth a shot if you’re in a similar situation.

SCCM OSD Boot Images & PXE

Standard

Lately, I’ve been working on a project to deploy a customized Windows 7 MDT task sequence via SCCM 2012 OSD. We had questions re: PXE boot image handling and selection- specifically how SCCM OSD PXE would handle multiple boot images (especially of the same platform.)

We created a new customized (x86) MDT boot image for the project, and had not made it available to PXE. Our old existing (non MDT) x86 and x64 boot images were PXE enabled. Since the new task sequence was using a new boot image that was not available to PXE, after we deployed the TS to the “All Unknown Computers” collection, our PC Technicians were no longer able to image new/unknown systems via PXE. Whoops!

When a system PXE boots, SCCM basically determines which task sequences are available to it, and picks the boot image referenced in the most recently deployed task sequence. If the task sequence you then select uses a different boot image, the system will download it and boot up into it after restarting. In our case, I suspected that Unknown Computers could no longer PXE boot, because the most recent task sequence deployed to that collection was referencing a boot image that was not available to PXE. For more detailed explanation see these posts:

http://blog.configmgrftw.com/boot-image-selection-configmgr/

http://blogs.technet.com/b/michaelgriswold/archive/2012/01/12/which-winpe-will-you-get-from-a-pxe-boot.aspx

We decided to PXE enable the new custom (x86) MDT boot image (by checking the “Deploy this boot image from the PXE-enabled distribution point” checkbox on the “Data Source” tab of the boot image.) I wanted to see what would happen to the old existing x86 boot image.

I checked the \RemoteInstall\SMSImages\ folder structure on our SCCM PXE DP server, and verified that a new folder had been created with the new boot image’s ID. The other x86 and x64 boot image folders were also there.

During testing we confirmed that systems PXE booted with the expected (most recently deployed) boot image. So, the two different x86 boot images coexist just fine on the same PXE server. (We will most likely switch the old task sequences over to use the new MDT boot image in the future, but wanted to keep them both around for now.)