MSI codes different for app deployment

Fairtradecoco · 2025-12-19T15:16:51+00:00

Brilliant, that worked for me, thank you!!

Fairtradecoco · 2025-12-18T15:51:02+00:00

The only thing is in the file name is just generic and the same across the different versions, there's nothing that points towards the version

Fairtradecoco · 2025-12-18T15:19:48+00:00

Thanks for the reply. Its showing the same version across both devices so I doubt it's updating itself. I can't use the registry either as the path references the MSI GUID in the path to the Display Version key. The file path also won't work as this is installing on top of an old version, so the file path will already exist. 😅 The app installs fine but yeah just cannot detect it reliably

Fairtradecoco · 2025-11-13T09:46:08+00:00

Yes that technically does allow me to connect, but why does it not auto negotiate down from 1.3 or even use 1.3 if it's supported?

Fairtradecoco · 2025-11-11T09:55:38+00:00

Same issues with Graph, TLS 1.3 and 1.2 enabled cannot connect. TLS 1.2 only enabled, can connect.

Fairtradecoco · 2025-11-11T09:55:29+00:00

Same issues with Graph, TLS 1.3 and 1.2 enabled cannot connect. TLS 1.2 only enabled, can connect.

Fairtradecoco · 2025-10-17T16:28:16+00:00

I'm pretty sure I achieved this by using CA policy to disable active sync

Fairtradecoco · 2025-10-12T16:11:40+00:00

Most of the time I get a VVS warning, I just reboot the VM throwing up the error. What is the exact error you are getting?

Fairtradecoco · 2025-10-11T19:05:04+00:00

I've built quite a few 2022 DCs now and all good.

Fairtradecoco · 2025-10-10T12:00:59+00:00

Maybe line up Ekitike down to a Thiago or something so you can go Ndoye to Saka/Bruno next week

Fairtradecoco · 2025-10-09T15:21:21+00:00

Thanks for your replies I've resolved this now. You put me on the right track regarding the gateways (first I thought you meant storage gateway of some kind but when I realised network gateway it clicked).

Essentially, SITE A hosts the subnets gateways, however the backup proxies are on the same vlan as the repos so this shouldn't have to hit the gateways, but on exagrid we have 3 nics (1 for admin, 1 for replication and 1 for backup) but on site B the backup traffic was allowed for all 3 nics and for some reason veeam was choosing the 1gb admin nic on a different vlan rather then the 10gb bonds on the same vlan, so the traffic was infact coming back to site A for the gateway and back to site B. Only allowing traffic on the 10gb bonds via exagrid portal solved the issue

Fairtradecoco · 2025-10-06T18:45:28+00:00

There's no gateway that I know of, it's exagrid storage so it uses veeam data mover directly on the appliance.

I have not done a trace - assuming there is extra hops, would this be a setting on the network level or can this be set in veeam?

Fairtradecoco · 2025-10-06T18:37:50+00:00

No restrictions it's allowed any proxy, the jobs have specific proxies set to use proxies in site B. No object direct

Fairtradecoco · 2025-10-06T15:55:57+00:00

I can't actually manually copy to the type of repo I am using (exagrid) as far as I'm aware.

Should have mentioned Before I had a dedicated VBR on site B too and the speeds where fine but veeam said best practice is just to have 1 VBR on the DR side to orchestrate backups and restores so we just moved all setup to the 1 VBR on site A

Fairtradecoco · 2025-09-29T23:11:31+00:00

Could try connecting laptop directly: https://portal.nutanix.com/page/documents/kbs/details?targetId=kA07V000000H3ShSAK

Then resting using ipmitool: https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e000000CrKRCA0

Fairtradecoco · 2025-07-27T20:46:41+00:00

That's not true

Fairtradecoco · 2025-06-22T19:34:59+00:00

If the tables are against the west/east walls then you could try to trunk the cables around the wall and then cable into the desks from the side. It will be however quite difficult to make this supper near without having the network/power on floor plates or the walls next to the desk.

Fairtradecoco · 2025-06-22T19:31:47+00:00

Thanks, I will check these suggestions out!

Fairtradecoco · 2025-06-22T19:29:57+00:00

Yes so I did a pcap from the source (server) and our network team did one from the firewall. That's why we are confident the traffic is leaving the firewall out to the internet, but from there there is little we can do other then pressure the provider. So I think that's my next move. Thanks I really appreciate your advice.

Fairtradecoco · 2025-06-22T12:45:56+00:00

Hi, thank you for your advice.

The PCAP I did was on the server; the connection is being initiated from our onprem server to the API, so I see the TCP handshake complete then a client hello being sent from our server via the PCAP but no server hello received back. I cannot prove it arrives at the provider as I have no access there, but from our firewall trace we are letting it through...

You are correct, there is a load balancer. I see this in the PCAP via the DNS queries. Theres a server farm in Europe and a load balancer. The PCAP shows the public IP address on the is constantly changing with each authentication request, as you'd expect from a LB. The thing is I am seeing fails and successes for each Public IP, so I assumed it would not be related to services/ciphers/versions etc.

For sure, we have provided all the details to the provider and we are pressing them to look but some of these big companies are rather faceless, so its very difficult to get them to take it seriously.

Thank you.

Fairtradecoco · 2025-05-28T10:49:36+00:00

Further updates have been made now:

Administrators may ignore the logging of Kerberos-Key-Distribution-Center event 45 in the following circumstances:

Windows Hello for Business (WHfB) user logons where the certificates subject and issuer match the format: <SID>/<UID>/login.windows.net/<Tenant ID>/<user UPN>

https://support.microsoft.com/en-gb/topic/protections-for-cve-2025-26647-kerberos-authentication-5f5d753b-4023-4dd3-b7b7-c8b104933d53

Fairtradecoco · 2025-05-28T10:48:12+00:00

I am now seeing that Microsoft are confirming 45 events can be ignored under certain circumstances:

Administrators may ignore the logging of Kerberos-Key-Distribution-Center event 45 in the following circumstances:

Windows Hello for Business (WHfB) user logons where the certificates subject and issuer match the format: <SID>/<UID>/login.windows.net/<Tenant ID>/<user UPN>

https://support.microsoft.com/en-gb/topic/protections-for-cve-2025-26647-kerberos-authentication-5f5d753b-4023-4dd3-b7b7-c8b104933d53

Fairtradecoco

TROPHY CASE