Forum Replies Created
-
Posts
-
I did some testing, and it look like the change from Local to network account is more involved. I Installed WMS 3.5 with local account. Put a network account into Allow Log on as a service. I then update all Dell WMS service to use a said network account. Then rebooted the servers. The only service that started, post reboot was Dell WMS: memcached and Dell WMS: MQTT Broker, all other service did not start and produced error when manually started.
The BIOS is a manual push. You have to copy the EXE to a USB, and apply via the Update Bios option in the boot menu. I did it and can confirm it does work.
Thanks for your response CG.
I wanted to upgrade to WMS 1.4. It has many new features in WMS that I see value in implementing i.e file repo sync, but file repository proximity to client “algorithm” was a showstopper. WMS 2.0 passed my various tests, and repository issue is addressed. WMS 2.1 looks promising, but value adds is low for me, I will wait longer prior to implementing. Listed Below are the various EOL HW and OS I successfully tested against WMS 2.0. An additional steps I would took for the EOL clients is to upgrade to the latest greatest WDA and platform tools available. YMMV.
Suse Linux 11.3.110, WDA 2.0.13-00.1
HW – 5010ThinLinux 1.0 1.0.7 , WDA 2.1.23-00.02
HW – 5020Win 10 Enterprise 2015 LTSB, WDA 14.2.0.51
HW – 5020 Image Version 11.040A79.30GBI did check the Release notes(Linked Below), it is listed as supported. I think it was a fluke, as now as is well.
Nothing special in WMS, just select the script for the app policy. I would say check your script just in case. You can reference link below, it is how I approached a PS script to add a task for local User account to the Task Scheduler. It seems application policy run’s under System account, so you skip specifying the -User parameter to register your task. I would recommend you make a script to remove the task added.
Not sure about newer WES Bios. However on the 5020 client, the ZIP file downloaded from Dell support site needs to be extracted and then EXE file found in WIE10 folder put into into “repository\osImages\zipped”. However, I think applying the firmware fails, I need to test.
Thanks. I get the part of assigning subnet to repositories. But I am still unsure why i would prioritize a subnet over another. I am referring to this passage one sees when subnet mapping are assigned to a repository.
Optionally a numeric priority can be assigned to a subnet or range.
Priority value is from 1 to 2,000,000. The higher number, the higher the priority. Place priority number inside parenthesis. For example 10.10.10.x (100) where 100 is the subnet priority. Default priority is the order of subnets in the list (the top ones have higher priority than those below). Manually set priority has higher priority than default one.If I prioritize a subnet in repository A at a higher number than repository B, does that mean the client will reach out to A first. It is just not clear, and the documentation is very minimal on this feature.
FYI I am running WMS 1.3. The only option available is to dismiss the warning, and view subscription(Screenshot Below). Should I check somewhere else? When I dismiss the warning it goes away for the time I am logged into the session, but next session it returns.
I am pretty sure the agent retains WDM settings, but I would recommend you setup a test environment. Being that you are only using DHCP options, SRV & TXT record testing should be relatively easy to setup during your transition. You just need to test on a subnet that has options, and then on a subnet that does not have DHCP option tags defined. For the subnet with DHCP options, setup the new DNS records, then restart a client to make sure it continues to report into WDM.
BTW, the manual contains what I have identified to WYSE support as wrong FQDNs fro WMS TXT records. WYSE support has not gotten around to updating the manual since WMS 1.3 manual. I have called out the TXT records identified below. You do not need to define the _WMS_GROUPTOKEN TXT record if you do not have ThinOS clients.
WMS Manual Recommended TXT Record
_WMS_GROUPTOKEN._tcp.<Domainname>
_WMS_CAVALIDATION._tcp.<Domainname>What Works for Me
_WMS_GROUPTOKEN.<Domainname>
_WMS_CAVALIDATION.<Domainname>Sounds like a good plan. If all your clients are already registered to WDM, you can go ahead and setup the WMS SRV record, and sunset the DHCP options. This way when you upgrade WDA, unregister the client from WDM, and finally reboot, client will automatically register to WMS .
Alternatively, if you are still registering net new client to WDM, then you can have the DHCP option in place alongside the WMS SRV records. The DHCP option will be recognized first by the client, and once you are ready you can register the client to WMS. Once fully migrated then you can sunset the DHCP option tags. Or stick to you current plan.
Another option, thought slightly more complicated and more work. I would recommend using the first approach and then applying a custom image(Factory image with latest WDA) via WMS. You will lose stetting like computer name, but will have a fresh new install with client checking into WMS, applying only setting you desire, and dumping any orphaned or adopted settings.
My 5020s came with Windows 10 installed. I wonder if you can upgrade your 5020s to Windows 10, firmware can be downloaded from https://www.dell.com/support. It is also EOL, so don’t expect anymore updates. I know in the past they offered a Windows 7 to Windows 10 upgrade option on the 5020, but did not see any option for Windows 8. However, maybe you can just overwrite existing image altogether with Windows 10 image. You may want to do a full clone of you SSD prior to trying this, i.e.. Clonezilla, so if FUBAR you can restore
If I was in you shoes I would migrate to Linux solution purposely made to be run as a thin client or roll your own. Prior being the easiest option as the solution will have the OS and management console, if you roll you own you need to come up with a management solution. I don’t like Windows as an edge device, in my opinion the manageability is not as easy as Linux. The 5020 HW is totally capable of running Linux. It sad that Dell does not offer the Linux migration option, they would rather keep their customers on a HW upgrade path. Which isn’t bad as you don’t want to end up with broken HW after many years of use.
WMS 1.4 is not all disappointing. It does have a lot of new features I like i.e.. export/import configuration groups, preserve device exception, automatic replication of repo files, application policy timeouts, etc… I would upgrade to it if it was not for this issue.
I did noticed in the WMS 1.4 Release Notes mentions this topic in section titled “Dynamic assignment of application policy to a repository”. It does confirm servers on the same subnet are prioritized “Device downloads applications from the file repository which is in the same or nearest subnet” and “If one repository is offline, the policy is pushed from the next nearest repository”.
Turning of file sync would not solve the problem. Once WMS see the same file on two servers, those two server will allways be grouped to deliver that file with or without file sync.
Based on my math even a server on the same subnet still shows WMS server as the lowest result. As mentioned earlier result is a negative number, server on the same subnet is the lowest positive number. So hopefully the logic does not deal with negative numbers but still TBD.
