- This topic is empty.
1. May 2012 at 23:10 #7302
So we’ve moved our clients out into our production environment and set up our production WDM server. After a long battle with compatibility issues with 4.9.0 and 4.9.1 trying to solve this problem, we’ve rebuilt our server (thankfully it’s a VM) and installed 4.8.5.
We schedule a package – pulling an image or sending an update – and it sits in the queue and does nothing forever. We’ve had to make some changes to our base image and now we can’t pull the updated image at all – and we still have almost 40 clients to push it to by Friday!
I’ve rebooted clients and I’ve rebooted the server. I’ve read several threads on here that suggested altering scheduling preferences (ie Time Bound Rollout) or clearing db tables (ie “job” tables – MDTools doesn’t show me a job table, and Query can’t connect). I’ve manually set the server’s location in the WDM control panel on the client, both machines can ping each other, Windows Firewall SERVICE is disabled on both machines.
I built this image using WDM 4.8.5 on a Windows 7 workstation, and now in production we’re running WDM 4.8.5 on a Windows 7 VM. I’ve tried updating the hAgent on the client, but of course the scheduled package won’t go anywhere. I haven’t yet tried to manually update the hAgent yet – I believe it’s running v22.214.171.124, the version 4.8.5 ships with which I’ve read is buggy, but none of the reported bugs look like this, and it worked before! This is driving me crazy!
I ran a diagnostic report and learned something fun – the computer we’ve installed WDM on has two network interfaces, since we also use it for managing our citrix farm and SANS. The diagnostic report shows hServer listening on the wrong interface (the private interface dedicated to the SANS). How can I change that configuration? I’ve checked IIS settings so the http and ftp servers only listen on the public interface, but hServer’s still on the wrong one.2. May 2012 at 15:34 #22212ConfGenKeymaster
- Total Post: 10966
- Jedi Master
You have to adjust the binding order to make the WDM nic the first one.
WDM is only using the first bound NIC.
CG2. May 2012 at 17:33 #22214
I changed the bindings in IIS for http and ftp to only bind the public interface – didn’t work. I did use MDTools 3.0 to edit the database table “Servers” and found a few entries with the wrong address – editing these manually, saving, and rebooting got the right IP addresses to show up in the diagnostic, but hServer is still showing as failed in the diagnostic.
Software Repository Information
Started 5/2/2012 11:16:40 AM...
Status Name Path Protocol Status
CONNECTED MASTER 192.168.102.175 FTP Connection to the repository succeeded.
Started 5/2/2012 11:16:40 AM...
Status Server Port Checked In Checked Out Response
FAIL 192.168.102.175 80 5/2/2012 8:05:52 AM Could not connect
Standard Service Information
Status Server Port Checked In Checked Out
CONNECTED 192.168.102.175 8008 5/2/2012 9:16:32 AM
If I visit the URL in IE http://vwmgr/hserver.dll?&V99 it works fine, returns the time stamp. If i view it by IP http://192.168.102.175/hserver.dll?&V99 it fails – not found. DNS returns the proper IP address when I ping the hostname.
So anywho, if this is binding order, how do I change the binding order for WDM?
I’ve also disabled the second NIC in Windows, so it’s not even active now.
I had set hostnames in IIS as part of troubleshooting – removing those gets the IP to work now, so the diagnostic page comes up green all over. But my package is still not rolling out, and if I try to pull diagnostic information from the client, it returns: &00|3. May 2012 at 14:23 #22222
OK we got something working – set the ip of the manager on the client manually, edited the database so the manager runs on the right interface, and a lot of playing with it until I was able to pull the image from my client – yay!
Now when I go to push the image to another client, if it actually starts pushing and doesn’t just sit in the queue, it dies early on in the process – the Linux imager picks up dhcp, connects a couple of times to the management server, and then dies with the error:
/bin/sh: can’t access tty: job control turned off
And then it just sits at a prompt. Rebooting goes through the process over again and ends in the same place. I have to delete the job from the queue in the manager and reboot a couple of times in order for it to activate the OS partition and go back to Windows.
The only thing I can think of is that, since most of the clients are still pointed to our test management server, rather than manually update all of them to point to the proper server, I reinstalled WDM on the test machine and tried to push the image from there, expecting that the new image (which points to the right server) would fix it for us. But if it’s because I’m using a different instance of WDM, that’s a problem because we’re putting it on a laptop to push to other clients at a remote location instead of pushing a million gigs through a 6meg vpn pipe.
Another thing I noticed is that the package is type “Merlin” on the WDM instance I pulled it on, but on the other machine and on the laptop when I import it it’s of type “Wisard”. I’ll give it a try using the “convert to merlin” option and see where that goes.
That didn’t take long – new error:
[Error:Could not download file /rapport/MECA_FSS/BCB0.i2d as C:UsersTWelchAppDataLocalTempTempSWPkgBCB0.i2d] [Ftp socket connection error:Not Available.][Ftp error:down failed. Could not get the file size.]
There is no i2d file in the image folder. This thread suggests the lack of an i2d file might be related to the job control error I’m getting.
In the machine I pulled from, it says image type: Merlin, in the second machine after import it says image type: Wisard. I checked the script, it says Merlin. Looks like it’s a manual update on all the clients to point to the new server, and pushing all these images over our VPN is the only way to go… Hope it works :/8. May 2012 at 14:23 #22274
So just to wrap all of this project up – we decided the best way to go was to rebuild a new image and pull it to a local instance of WDM at the second site, then push it from there to the rest of the clients. I think most of our problems stemmed from trying to import an image.
As far as getting WDM to pull or push packages, it seems like the software is just really floozy. All of the server IPs in the database (rapportdb/servers) need to be pointing to the correct interface, Windows Firewall exceptions need to be created (this does not appear to be automatic with IIS), and clients may need to be configured manually to point to the correct server – even if DHCP is configured and manual network scans are run repeatedly, it’s just not consistent. But we are slowly succeeding in getting the clients at the second site to check in at our primary management server.
In other news, I discovered that, when a client is properly registered in WDM and connected, clicking the “update device information” button can (of course it’s not competely consistent) force a package to run immediately instead of waiting for the next checkin (which it seems may never occur). This was a very useful discovery for me, I hope it helps someone else out.
My next question is whether or not I can push update packages, such as printer drivers, without having to push a full OS image. My clients are C90LE7s running WES7. I should probably start a new thread for that…
- You must be logged in to reply to this topic.