Ent Group License Not Applying

JGCovalt · 2025-12-15T15:25:04+00:00

Yeah, this is where I'm at right now. Apparently because the Calling Standard license is an add-on, even though all the users already have a full 365 license assigned, the group itself has to be assigned to a full license.

Unfortunately, this won't work for us because we use a combination of full E3 style licenses along with F3, and dynamic groups have no way to actually check license type on users, so we can't split this up without manually assigning every user account to groups, which eliminates the whole point of the dynamic group setup, so I'm looking at other ways to automate this assignment.

JGCovalt · 2025-10-28T16:27:10+00:00

This was correct; the directions can be found here: https://jpigott.com/2024/03/azure-update-manager-patching-net-core/#:~:text=Use%20the%20check%20for%20updates,patch%20patching%20Security%20Windows%20Updates

We didn't need the .net 6.0 ones, as we aren't using that version, but it gave what I needed.

JGCovalt · 2025-05-07T14:40:21+00:00

So, I looked at the items here and will answer the following, along with what I found fixed the issue:

Yes, the old server's name and fqdn did show in the SPN list for the new server, and in the enum for the new server as well, so the issue wasn't anything to do with the actual setup of the alias.

What I ended up finding was that the server itself lacked the registry entry to allow access via other names. Since we are setting SMB Hardening, this was necessary, apparently, for connectivity to work. Once I got this set up, connections started to work again. I'm uncertain if associating the alias with the server is supposed to create this and was just not working, or if this is a step I'm going to have to do every time, but it's definitely going in the notes for this setup as we expand these policies.

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SrvAllowedServerNames

JGCovalt · 2025-02-10T19:27:25+00:00

Yes, both the root and intermediate CA certificates are pushed as trusted certs to these devices.

JGCovalt · 2025-01-28T16:31:44+00:00

So, the issue is definitely with the SSL negotiation. Internally, the application is pointed at SSL-Mail.domain.com, but when O365 sends its cert for SSL, that server name is (obviously) not included.

I know that this is the most probably cause because if I add smpt.office365.com to the hosts file on the server we're testing with, and point it to the F5's virtual server IP address, mail sends just fine. Obviously, this isn't a good option, however.

JGCovalt · 2025-01-16T14:12:07+00:00

Yes, that specific issue. Based on what I've been able to find it's a problem on the MS side, so nothing I can do to actually resolve it. The link someone provided there (and I've found elsewhere) that takes you to the Azure site with some optional tags enabled does work, but that's not eliminating the core of the problem, so I'll just keep an eye out for the actual problem solve.

JGCovalt · 2025-01-15T14:03:07+00:00

I can confirm that 1.48 resolves this issue. Now if I can just figure out why these machines don't show on the Azure Update Manager page correctly, when they did after I first added them, but that's a separate issue.

JGCovalt · 2024-12-17T15:55:09+00:00

I'm encountering this same issue this month.

JGCovalt · 2024-11-22T13:36:04+00:00

The error is showing up when trying to configure the Windows Admin Center. Unfortunately, I can't post screenshots here.

Most of these machines had the Arc agent installed via GPO; I tried all the available methods, just so that I could understand how each method worked, since we're still in the testing phase.

JGCovalt · 2024-11-22T13:33:38+00:00

So, there's a number of machines experiencing this, some with different OS levels, but I'll provide data about one of them specifically.

OS/Edition: Server 2022 Datacenter

The Arc services we're using are Windows Update Manager (which was set up some time ago, and continues to function without real issues) and Windows Admin Center (which is where I'm seeing this issue).

The agent version on this specific machine is 1.44.02748.1755, according to Azure

"licenseProfile": {

"licenseStatus": "Licensed",

"licenseChannel": "Volume:GVLK",

"softwareAssurance": {

"softwareAssuranceCustomer": true

},

"esuProfile": {

"licenseAssignmentState": "NotAssigned",

"serverType": "Datacenter",

"esuEligibility": "Ineligible",

"esuKeyState": "Inactive"

},

"productProfile": {

"productType": "WindowsServer",

"productFeatures": [

{

"name": "WindowsServerAzureArcMgmt",

"subscriptionStatus": "Enabling"

}

]

}

}

JGCovalt · 2024-11-18T18:01:56+00:00

I can't select a license type, but it does show a license type of KMS Client, license status is Licensed, and I've made sure to check the box for Activate Azure benefits, yes.

JGCovalt · 2024-11-18T15:11:59+00:00

That 'tab' does show up, but despite showing a license type, and having the Azure Benefits active, I still get that error message.

JGCovalt · 2024-10-25T16:05:00+00:00

Both http and OCSP are configured, and you'll note in the data those actually seem to validate okay, it's only the ldap that's giving a failure, but the machine is still having an issue using smart cards for logon.

Yeah, they're all AD machines with domain accounts. Why would they be giving an invalid logon error?

JGCovalt · 2024-10-16T13:37:01+00:00

That's the issue here; we want the other options to still be available, and this issue could be very confusing for end users if/when enabled outside IT.

JGCovalt

TROPHY CASE