Who is this really?

You really should identify yourself so we know who we are talking to (not just that you are a "System Administrator").

Anyway, the first XPP release that was qualified with Win2016 was the XPP 9.2.0 release. The first release qualified with Win2019 was the XPP 9.4.0 release.

We have never tried running XPP 9.1 on either Win2016 nor Win2019 platforms. You might want to seriously consider upgrading your version of XPP if you really want to change to Win2016/2019 platforms.

What do you mean by: "Is there anything on being sent over the ISV that would prevent X windows from opening"? (which according to a web search can only seem to mean "Independent Software Vendor")? I'm not understanding what you mean by this question and the reference to "ISV".

And another question that comes to mind is: Have you checked the firewall settings to make sure that it's allowing the (ports needed for the) Xserver software?

I apologize as I'm brand new to XPP and its terminology so I will try to better explain. We were in a position that had us upgrade just the OS from 2012R2 with XPP 9.1 The hostname, MAC address, IP, etc. did not change on the server, everything remained exactly the same. All of our licensed features work except the ability to use pathfinder to view/edit jobs and styles. When I disconnect the network on the machine, that pathfinder pulls up x-windows and works fine. When the machine is online, that is the only feature that doesn't work. I can rule out the OS being the issue on that.

When reviewing the RLM settings via port 5054, I see the license file is good and it's established the dynamic port on the ISV, sdlxysoft. I've reviewed the RLM, debug and sdlxysoft logs, as well as setting up the report logs. I'm observing denials under the sdlxysoft statistics and I'm guessing that's when trying to open pathfinder stuff to view jobs and styles. I can't find out why or where the denials are happening because it's not reported in any of the troubleshooting logs. We don't have the firewall on, just as before the upgrade. When I mention is there anything being sent to the ISV, I'm referring to the license pool status from the RLM administration console.

Products include advp, compose, llfp, opt-ntrv, opt-srty, xppcompare, xppcpu, xyvu-x. Again, I'm only guessing that xyvu-x is PathFinder? Our count is two that is user base and doesn't report any usage. I can see ADVP usage populating the correct hostname and compose is running fine in the background services.

While I understand it's XPP 9.1 and obviously, the easy answer would be to upgrade. I've begun working with SDL to draft us a quote to get back on support and look at the new version but in the meantime, I'd like to see what is missing since I've proved that it runs on Server 2019, just in a disconnected network state. Anyone know how to view denials from RLM and to see what is assigned for the User share on our products? Is it a permissions issue? We didn't do any crazy setup with the special xpp groups mentioned in the instructions and I've tried a domain administrator and a local administrator account on the server.

As for my name, I'll change it. This is my first time doing this and clearly set it up under a shared email with my operations team. I appreciate any insight and help on this odd issue.

Well, you could at least have identified yourself and/or the company you work for in your last post.

I'll only add a few things to what I've already said.

PathFinder itself (the Windows Explorer like GUI) does not use any license tokens. The token for the XyView editor is xyvu-x. From what you've said it doesn't sound like you have an XPP licensing problem, but have some kind of strange problem with the Xserver. There is no connection with XPP licensing and the functioning (or not) of the Xserver.

If the XyView (which is an X11 window in the 9.1 release) does not open successfully, then it will not consume a license token (it will never get there).

There's really very little chance anyone will be able to help you with this problem in this forum. IMO, you will need help from support if there is any chance to get this working with your retired 9.1 release running on an unsupported version of Windows for that release. So, I recommend you speed up the process to get on support (as far as it depends on you).

But it might be the case that the MKS Xserver delivered with XPP 9.1 (if that's what you are using) will just not work properly (in all cases) on the newer version of Windows.

All the more reason to upgrade: The newer version of XPP on Windows no longer requires an Xserver.