App Portal 2020R1 - Client is flagged as offline in App Portal when assigning catalog items

[Tipadu]

Hey everyone,

when we try to assign a catalog item to certain devices, they appear to be offline as we get the message "Client is offline and will be added as soon as it is online".

After checking ConfigMgr those clients are in fact not offline or inactive, they are managed and active.
When we try to add those devices, the error log says: "The conversion of a varchar data type resulted in an out-of-range value."

This error only appears for some, not all, devices.

1. Is it possible the error message is the reason the clients are flagged as offline?
2. What data/tables/columns are getting checked during this process, so we can validate if there are any wrong date formats or something like hat?

Thanks in advance,

[CharlesW · Accepted solution]

if looks like App Portal first gets the IP address of the machine from the App Portal DB by running the following query:

Select IPAddress from vComputer where MachineName = '<machineName>'

It then invokes the .NET API System.Net.NetworkInformation.Ping to first ping the machineName, followed by the IP address discovered earlier. the API is documented at the following URL:

https://docs.microsoft.com/en-us/dotnet/api/system.net.networkinformation.ping?view=net-6.0

Its not exactly the same thing as App Broker is doing,  but I'd try pinging using the machine name, from the App Broker server, followed by a Ping of the IP.. It would also be interesting to note what the IP is for this device.. Perhaps it is something out of the ordinary, which is triggering the exception to be written.

Typically, even if a machine is not pingable, you can still submit a request, and it will still be inserted into the collection.

[CharlesW]

To further clarify: When I say " It would also be interesting to note what the IP is for this device", I would like to know what the IP  is for the device, as returned by the query against the App Broker DB.

[Tipadu]

Alright, thank you very much, that was exactly the case. I'll accept it as solution.