Forum Replies Created
-
Posts
-
I can confirm:
- Cisco WebEx Meetings app v41.3.0.113
- Cisco WebEx Meetings plugin 40.10.11.15.4 (from Dell site)
- WTOS 9.1.1131
Thanks friend, I wouldn’t want you to open a ticket for me that isn’t what i was asking. I have one open I was asking if you had any access to a “Known Issues” list or bug report for WMS 3.1. I’m going to wait until public cloud is updated this Friday with the hotfix and retest SCEP to see how it performs
For the record, this was the one that finally got it working
[HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Spark Native] “isVDIEnv” = “true”, datatype:REG_EXPAND_SZ
Also, for obvious reasons, make sure your turn on the Citrix Virtual Channels for the different unified communications in WMS for the policy under Citrix Session Settings… Zoom VDI, WebEx VDI, Teams VDI etc.
I now have both Zoom VDI and WebEx VDI working.
@the0duke0 so this works and I appreciate the reply, however I would think this is not working as intended. In WMS policy where you are supposed to have the option of the Common Name of the certificate, WMS seems to be automatically creating it as .crt, you don’t get the option of defining it. I’m guessing this is a bug in WMS 3.1 559.
I am managing over 3500 devices, with 75% of the devices configured for internal corporate network use that need to do SCEP for 802.1x enforcement on Ethernet and Wi-Fi. I can’t upgrade these devices to 9.1 until this gets fixed.
Can I make it work, yes, but what happens with the Common Name issue gets fixed? To make it work i’m listing the Common Name in the policy as simply $SN and not defining the extension as I previously did $SN.pfx. If WMS 3.2 fixes this issue I need to change the policy again because $SN won’t get me anything without defining the extension.
I don’t know why SCEP has been such a pain point with Dell since moving to WTOS9.
@ConfGen do you know if there is a bug reported for this in WMS? I know you still have an inside track to Dell you’re always in the beta’s that I sometimes get invited to.Appreciate everyone’s feedback on this.
EDIT: I believe this to be a WMS issue and not WTOS, since I had SCEP working before and then it must have been something I didn’t notice immediately when Dell upgraded to WMS 3.1 on December 4 for public cloud. When I did an upgrade from 8.6 to 9.0.4024 I see the same issue where previously I didn’t so the scep_cert appending in the certificate name and adding .crt to every Common Name choice occurs on 9.0.4024 and 9.1 which tells me its coming from WMS.
In WMS policy for Services>>VNC I put the IP address of the machine I am connecting from in the VNCD Server Field and also specify the VNCD TCP Port of 5900. Also Enable VNC Prompt is active, Select Timeout Type = Accept, Timeout =10. I’ve been able to connect from the US to ThinOS 9.1 test devices we have in Hong Kong across our corporate network without issue.
Thanks @the0duke0
Just seems like thats not working as intended because for the Common Name the informational tag at the end of the box says to specify your client certificate name including extension, so its always been $SN.pfx, now it seems to force .crt to the end of whatever extension you specify which seems broken.
When selecting the cert for machine auth this is how it’s seen.
Creates another cert with the terminal name but in the same fashion TN.pfx.crt and for some reason the CommonName keeps coming in as *scep_cert_TN.pfx.crt
Bubbling this back up, SCEP was working in 9.0.4024, and while it works when I upgrade from 8.6 to 9.1 using $SN.pfx, if I reset the device to factory default and put it back in the same policy using $SN.pfx for the certificate name, the certificate comes out as SN.pfx.crt and when you go to select the certificate for machine authentication the name is *scep_cert_SN.pfx.crt which makes it impossible to set the certificate name by policy for 802.1x authentication.
Anyone else seen this?
So I’m an idiot and it took a glass of Glenlivet 12 to read the install package name for the BIOS listed as “ThinOS 9.1.1131 BIOS package v1.5.0 for Dell Wyse 5470 Thin Clients”…so we have to be on 9.1 to upgrade to 1.5…yeah I’ll be over here in the corner.
Alright, looks like I had to do this incrementally, but the problem still seems to be 1.5.0 package.
First 1.2.1 to 1.3.1, no issue, install successfully
Then 1.3.1 to 1.4.0, no issue, install successfully
Then 1.4.0 to 1.5.0, same message – Failed to install packages. error: [“Failed to install bios version: 1.5.0, error: can’t get start of pkg signing certificates”]
SHA256 checksum is valid. Will try downloading again.
I get the same message from WMS public cloud with http/ftp disabled. If you look in the event log them message comes up immediately on boot. Later in the event log you can see where http/ftp are disabled protocols.
My assumption is it’s triggering off of that, or not disabling that message when http/ftp is disabled.
That worked.
That is why you are the JediMaster and I am a mere LunchBox
🙂
Thanks again CG I really appreciate all your knowledge. It would be nice if this was in Dell’s admin guide. Just to be clear…
I’m using 7zip and unpacking DellHybridClient_1.1_1618.tar.gz to get DellHybridClient_1.1_1618.tar. Then I unpack DellHybridClient_1.1_1618.tar and get a folder labeled DellHybridClient_1.1_1618. Inside the folder are DellHybridClient_1.1_1618.bundle and DellHybridClient_1.1_1618.bundle.signature
The only one I need in the hybridClientApps folder is the DellHybridClient_1.1_1618.bundle file and I can delete the signature and the tar and the folder file?
