Forum Replies Created
-
Posts
-
You’re right, MQTT wasn’t working correctly. I checked the stratus.log. Since I edited the MQTT entries in the MongoDB, the wms server couldn’t resolve the external url. I added an entry to the hosts file and that was it. Stratus.log doesn’t show new errors.
Restarting devices does work now instantly, renaming still does not.
WMS shows:
Admin initiated Change Host Name - Test01 on WTxxxxxxxxx at 04/27/20 10:36:37 AM (Status: Successful )The client shows:
wms: received "Change Host Name" commandThe host name remains the same, though.
Update:
Restart commands do work, though they are not pushed instantly to the device. I changed the time for the devices to send a heart-beat to 5 minutes.
So, if I send a restart command via WMS, the device does nothing until it sends a heart-beat after 5 mins. It restarts right after that check-in. That does not really seem like “push-action” (more like “pull”, haha).
Also: changing the hostname still won’t work.
Thanks a lot XanDaph!
I successfully edited the MQTT entries and the client now shows:
WMS server: https://wms.example.com:443
MQTT server: tcp://wms.example.com:1883
The eventlog also shows “Connected to MQTT broker”. However, commands like restart or change hostname still don’t work…
I’m facing the same issue with WMS 2.0 (Standard on-prem) and ThinOS 9.0.
Since I cannot use ini-files with ThinOS 9 anymore I don’t know how to solve this. Although I’m not really sure MQTT is the problem. The devices register and check-in correctly with WMS after each reboot. However, changes made in WMS (like query, change hostname) are ignored. Plus, the devices do not send heart-beats.
When looking into the “Central Configuration” of a ThinClient, WMS shows the following settings:
WMS server: https://wms.example.com:443
MQTT server: tcp://WMS01:1883 (greyed out, cannot be modified)
Using the new Admin Policy Tool on the client didn’t work either. That ended up with the default MQTT server (us1-pns.wysemanagementsuite.com)…
Any way around that?
Do you have a package policy configured? Like Citrix Workspace App Pkg? If so, try removing it from your policy and try again.
Try this:
"C:\Program Files\DELL\WMS\MongoDB\bin\mongoexport" --db stratus --collection devices --type=csv --out C:\TEMP\Export\wmsreport.csv -u stratus --authenticationDatabase "admin" /fieldFile:"C:\TEMP\Export\fields.txt"Are you using a .bat- or .cmd-file? Did you copy & paste the command from here? If so, check the double quotes/quotation marks. Delete them and enter them manually and try again.
I’m running WMS 1.4 and ran these commands successfully a few minutes ago:
Batch file:
“C:\Program Files\DELL\WMS\MongoDB\bin\mongoexport” –db stratus –collection devices –type=csv –out C:\TEMP\Export\wmsreport.csv -u stratus –authenticationDatabase “admin” /fieldFile:”C:\TEMP\Export\fields.txt”
fields.txt
name
groupName
modelName
macAddress
ip
subnet
serialNum
devicePlatformType
cpuFamily
registrationTime
isOnline
isCompliant
isCheckinCompliant
isInstalledAppCompliant
isConfigCompliant
isCaValidationOn
isActive
flashSize
lastCheckinTime
lastConfigTime
timezoneName
lastLoggedInUser
hasAlerts
osCaption
osBuildVersion
mandatoryAppCompliantStatus
uptimeIt’s a Pro feature.
Check https://technicalhelp.de/topic/export-devices-from-wms-1-1/ for an alternative.
When it shut down and then you turned it back on, did it make an attempt to upload an image or did it immediately boot to Windows?
It tried but failed due to an outdated version of Merlin. But that was to be expected.
I found a tutorial on DELL’s website (for WDM, but still): https://www.dell.com/support/article/de/de/debsdt1/sln293831/prepping-a-wes7-image-for-deployment?lang=en
So yeah, it seems to be the right file. I’ll give it another go tomorrow…
Yes, there’s a folder “C:\Windows\Setup”.
Content:
AddUsertoUsersgroup.vbs
Admin2.bat
AdminAutologon.reg
AdminSCCM.bat
Autologon.reg
BAActive.exe
Customization_Administrator.reg
Customization_HKLM.reg
DeleteFreeSpace.exe
Disk_Size.exe
fbwf_shortcut.vbs
Flash.wss
Flash_Temp.wss
Hagent_Auto.reg
Hagent_Manual.reg
HAgent_UI.exe
HAgent_UI.reg
Initialize_Temp.wss
MUITSUSBPresysprep.reg
NetXClean_Auto.reg
netxclean_Manual.reg
OSActive_Temp.wss
PlatformAgnostics.vbs
PnPApp.exe
Powershell_Wordpad.vbs
RemoveUserfromAdminGroup.bat
RemoveUserfromAdmingroup.vbs
SCCMCapture.reg
SCCMDeploy.reg
SCCMPartition.txt
sccm_oem_EDM.vbs
scripts
State
SynUI.reg
Sysprep.reg
Sysprep.xml
User.bat
W7-OSActive.exe
WES7_CustomSysprep4man.bat
WES7_SCCM_AdminRunonce.bat
WES7_SCCM_Capture.bat
WES7_SysprepAudit3.batI ran the WES7_CustomSysprep4man.bat, it took some time and eventually the device shut down. On the next boot it had to configure windows for “first time use”. After that, my language settings were pretty messed up. I ended up with a mix of English and German. So… I’m not sure that’s the road to go?!
Hey MoPositive,
do you happen to know if your tutorial works for WES7 devices as well? Steps 1-4 are no problem. When trying to pull the image via WMS, I clicked on “Pull after Sysprep”. I assume that’s correct?! The client reboots and I continue with steps 6 and 7. However, on WES7 there’s no BuildMaster.cmd.
What should I do instead? “Just” reboot?
Do I HAVE to use sysprep? The image is used on devices with the exact same hardware.
Ok, forget it for now. I cannot even rename it from the Windows GUI. Seems to be a problem with the image… I’ll try to create a new one.
Correction: The status says ‘successful’ and the device DOES reboot. Host name isn’t changed though.
Hi Volker,
I got it working now!
I (again!) deleted and recreated all OS policies and deployment groups. I used the same configuration settings as before so I don’t really know why it’s working now but well… I successfully deployed a W10 and WES7 image so that’s fine with me! 🙂
Thanks a lot for your assistance!
Regards
Philipp
