Geeks With Blogs

News Clicky Web Analytics

web stats View David Caddick (davidcaddick@gmail.com)'s profile on LinkedIn

Search this Site!

Locations of visitors to this page
View My Stats eXTReMe Tracker
This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed within are my own and should not be attributed to any other Individual, Company or the one I work for. I just happen to be a classic techie who is passionate about getting things to work as they should do (and are sometimes advertised and marketed as being able to?) and when I can I drop notes here to help others falling in to the same traps that I have fallen in to. If this has helped then please pass it on - if you feel that I have commented in error or disagree then please feel free to discuss with me either publically or privately? Cheers, Dave
Thin Clients, VDI and Linux integration from the front lines.... Raw and sometimes unedited notes based on my experiences with VMware, Thin Clients, Linux etc.

Recently I found myself at a school down near Melbourne carrying out what should have been a relatively simple PoC (Proof of Concept) of 20 x BC2500 BladePC’s in an Enclosure with some T5730 Thin Clients, and initially all went pretty well and then I found that I had some issues with the SAM Registration service….. from the BladePC’s not communicating very well (or at all) with the SAM Server

BTW – SAM = HP’s Broker, Session Allocation Manager

So then I was thinking through some ideas about what the next steps might be to help isolate it?

Initially I was getting a note in the Application Event Log for all the BladePC’s that they are unable to contact the SAM Server, and yet:

  • they can ping it successfully
  • I can connect to the blades using RGS fine
  • The Windows Firewall is disabled for now
  • There are exceptions in the firewall any way for the SAM Service

So I then used WireShark to take a trace and isolated one conversation with a blade and the SAM Server and got it to translate the TCP conversation and the resultant HTTP reply from the SAM Server indicated an internal error – so I simply rebooted all the Blades and the SAM server and I finally got the devices registered – hurrah!! I thought I was out of the woods.

Then as the day wore on it appeared that after a period of time the Blades would become “Offline” with a red circle and the diagonal slash indicating they were offline and they would no longer respond – a reboot will get them going again.

Now if I was just troubleshooting this it would not have been too bad – but I was also seeing some other very curious issues like:

  • When I connected from the T5730 to the BladePC via RGS direct (no SAM) it is verrrrry slow (5 – 10min login)
  • When I connected from the T5730 via the SAM Client it is verrry slow just to start the Login process (even longer?)
  • Once connected the experience is not too bad (not real snappy, but just about useable)
  • Connecting a USB device to the T5730 to test Video causes the RGS session to drop – with no warning – before the Media Player comes up

Now was I right to suspect the network at this point? I’m not a Network/Switch expert, but I know enough to be dangerous? ;-) but it was starting to look like there was more than just a hint of coincidence with what was going on?

Curiously enough I’ve also found that while my laptop is connected to their network and using the proxy to gain access to the ‘net to get email that the connection to exchange keeps bouncing quite a bit and when I send an email it can sometimes hold in my Outbox for hours before finally getting under way….

Outcome – all now sorted – it would appear that even though the SAM/Altiris Server AND the BladePC Enclosure was plugged in to the Core Switches there was a ProCurve 2650 that was throwing out FCS Errors and causing a ruckus – this also happened to be the unit that I was trying to go through with the T5730 Thin Clients……

This morning a Network Guru from their integrator turned up and updated all the firmware on the Cores and 2650 alike, found the issues were related to the 2650 only, this was then swapped out for a temp unit – then it seemed like nothing was working at all with no connectivity to the Enclosure, then it was discovered that Spanning Tree was the cause of this, so that was hit on the head – and now everything has settled down nicely.

Good news is that apparently HP’s ProCurve Switches come with a lifetime warranty – I learn something new every day? – so as it turns out it’s not too bad?

So a day or two late, but finally back on track.

Incidentally, when I was trying to update the Firmware in the Enclosure for the Switch and the IA (Integrated Administrator) via a simple TELNET I was getting timeouts and errors, after this wayward Switch was replaced it all worked a treat.

Lesson:
As with Citrix and VDI, as well as BladePC/BladeWS, it’s always worth remembering that this is typically the first time that a network will have been asked to provide “real time” network performance. Up to this point even things like email are effectively only “store and forward” process’s so do not be surprised when a relatively simple PoC (Proof of Concept) shines a Spotlight on any Network issues?

I hope this helps others?

Posted on Wednesday, December 3, 2008 10:11 PM IT Management , VMware and other Virtualization tools , Thin Clients , HP/Neoware | Back to top


Comments on this post: Thinking of a Remote Computing Solution based on Citrix/VDI/BladePC’s? Make sure your Network is up to the task, or you might have curious issues?

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Dave Caddick | Powered by: GeeksWithBlogs.net