Tenant Attach, Applications and how it can bring value for your helpdesk

Recently we (Kenny & myself) engaged with a bigger customer to migrate multiple MEMCM environments into a new standard platform, the goal of this project is to unify the multiple companies.

One of our challenges was the Application delivery strategy. It was a heavy discussed topic as we faced the typical topic of “Application – Collection – AD Group methodology”, why change something that has worked for so many years ?

ServiceNow today is providing an application catalog for users to request their software, but once the software has been requested a ticket gets created and delivered to the helpdesk queue ==> where an engineer takes the user or device object and populates it in an AD Group. I guess most of us are familiar with this, since it’s probably the most common setup seen in a lot of companies.

As we are getting more and more user driven improvements in the latest version(s) of ConfigMgr, we wanted to take advantage of the nice and shiny new application approval process. Like the product team promotes, we want to avoid creating 500+ collections and instead be like cool kids going almost collection-less!

The goal was set, to go almost collection-less and have it fully automated using ServiceNow as the “orchestration” tool which will approve / trigger the approval requests. Due to hectic Project Planning etc. the full automation part will be integrated later this year, however we needed something now so that we could keep our “vision” of going collection-less and avoid creating any more application AD Groups!

This is where we thought Tenant Attach would come into play, we are not going to explain what Tenant Attach is. There are many good blogs about it.

One thing of Tenant Attach we are focused on is the “Application (Preview)” feature. Could this provide us with a temporary solution to approve / push the application installation part – to avoid setting up all these AD Groups and Collections again?

At our customer’s helpdesk, they don’t have real administrative privileges in the CM console. They are just capable of doing the normal helpdesk stuff (remote control, reporting + HW Inventory).

Now we have explained our scenario, let’s go technical.

We have our Helpdesk Group, which in our lab environment has 1 user in it called “helpdesk”

This user is synced as a hybrid identity to AAD.
Shoutout to Microsoft: it would be cool that there would be a possibility to use AAD Only accounts in CM console .. a lot of customers have on-prem only Admin accounts & AAD Only Admin accounts!

I’ve setup a few test deployments to my “test – user collection”, 2 of them require approval (based on client settings they will be hidden in software center)

Our test device:

So, that’s looking good. Let’s go into Tenant Attach now (everything has already been setup & synced)

We’ll be using the helpdesk account, since he/she will be “handling the ticket”:

Let’s open the application (preview) feature

The user targeted applications are visible, you already notice that we have more applications visible compared to what the actual user would be able to see in software center (this because we hide the apps that would need approval)

Good .. now let’s try to install 7-zip

Hmmm, not what we were hoping for .. time to open the logs. Browsing the documentation it seems that we should look the adminservice.log

Ok, so the adminservice is trying to execute the SMS_ApplicationRequest.CreateApprovedRequest as my Helpdesk user .. so this means that my helpdesk user does not have enough privileges in ConfigMgr to execute this task.

Now the tricky Part, and this will be the case in most companies, what if your helpdesk doesn’t have any real administrative privileges in Configuration Manager ? as you already noticed our helpdesk user only has “Read Only Analyst + Remote Tools Operator”, we don’t really want to give them more.

Back to the documentation part, this brings us here

So let’s create a custom security role for this and link it to our helpdesk group:

Back to Tenant Attach & let’s try again.

Oh yeah, this is looking great.

Ok cool, but now let’s try it for one of the hidden apps. Because that’s the main goal behind this exercise.

Yes! It works

Checking the console now, we can see that following approvals have been created & approved via the Adminservice.

If you’re still reading beyond this point, that’s it. A (not so) quick write-down of what we have been trying to accomplish.

This is a really cool feature, that i’m convinced about will bring a lot of value to your helpdesk. You can enable your helpdesk to do these actions without having a footprint on the CM console. (using your phone for example when your out for grocery shopping)

If you’re a small shop, and you’re not looking to invest in a ServiceNow or other tool, this is an easy and transparent way to empower your helpdesk.
Bigger shops who’ve been looking for a way to get away from those pesky install/uninstall collections. look into it, you might have the same use-case as we have just worked out.

Kim, out.

Enterprise Mobility : In the land of NDES – Where one eye is King and you need to watch your CRL Delta files

I was doing a EMS POC and deployment of certificates on mobile devices was a requirement. So I needed to setup an NDES server with a separate Subordinate CA for MDM , NDES Server and SCCM Certificate Registration Point (CRP). Big deal I thought as I did it a already multiple times. At my customer we worked close with the server team and setup the infrastructure which was working fine at first sight.

After a reboot of the NDES server I was struggling to get the Network Device Enrollment Service (NDES) up and running again as it would throw me an error 500.

Image result for error 500 ndes

The event log of the NDES Server told me the following:

The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect.
The Network Device Enrollment Service cannot be started (0x80070057). The parameter is incorrect.

When the service starts, it searches for two certificates that are used by the service :

1. The service searches in the machine MY store AND

2. The certificate must have the following extensions AND

For the Key Exchange certificate:

– ExtendedKeyUsage: “Certificate Request Agent”

– KeyUsage: Encryption (0x20)

For the enrollment agent certificate:

– ExtendedKeyUsage: “Certificate Request Agent”

– KeyUsage: Signature (0x80) 

3. The certificate must not be archived AND

4. The computer must have the private key for the certificate AND

5. The certificate must be issued by the same CA that the service is configured for AND

6. The certificate must have a valid chain AND

7. If there is more than one certificate for either of the certificates that meets the previous criteria, the service will select the most recent one (the latest that was issued)

Troubleshooting certificate issues will require you to enable the CryptoAPI 2.0 Event Logging :

The CryptoAPI 2.0 Diagnostics is a feature available from Windows Server 2008 that supports the trouble shooting of issues concerned with:

– Certificate Chain Validation

– Certificate Store Operations

– Signature Verification

Enable CAPI2 logging by opening the Event Viewer and navigating to the Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\CAPI2 directory and expand it.  You should see a view named Operational.Next, right-click on the Operational view and click the Enable Log menu item.

Searching the right information under the capi2 operational log :


I was quite sure, that I was able to download the CRL (Certificate Revocation List) and I double checked that by browsing to the URL ‘.crl”><NameOfYourSubCA>.crl’ and I was able to download the file. When digging deeper in the eventID’s , I found at EventID 42 , the following URL ‘.crl”><NameOfYourSubCA+>.crl’ was shown. This means it was looking for the  availability of the Delta CRL, which was visible on the web site of my CRL:


When I finally tried to download this CRL Delta file, it failed. I remembered myself, that IIS is treating the + sign very differently in URL’s.

I needed to set the setting “Allow double escaping” in the web.config file as shown below :


After enabling this, NDES was able to retrieve the Delta CRL file and start the service gracefully.

So if your NDES Server is throwing “The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect.”, do not only check your certificates on the Server, check also your CRLs and Delta CRLs!

Hope it Helps,

Kenny Buntinx

MVP Enterprise Mobility


Enough talk, let’s build
Something together.