1) We always staged updates internally using WSUS which allows limited testing. 2) GPO's are not a good way to deliver critical updates, but they are what you get "out of the box" and "systems centre" is an arm and leg in dollars...
> -----Original Message----- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Alex > McWhirter > Sent: 27 May 2016 23:06 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org> > Subject: Re: Windows use in medical spaces (Re: vintage computers in active > use) > > > > Where Windows generally fails in my experience is in the idot proofing / > automation mechanisms. I can really only comment on Windows 7 as it's what > we use in production on our client boxes. > Granted this is a different environment where all machines have access to the > internet and thus Windows updates / aplication updates. > Group Policy is something I struggle with regularly. Automatically feeding > Group Policy updates to clients is not always straightforward, especially when > you need to push application updates to fix important security or > functionality > bugs. Yes, you can gpupdate /force, but that's only seems to work about 50% of > the time and requires user intervention on an admin account. > I've seen issues with the Print Spooler randomly crashing from a partially > install > printer through group policy. Some kind of event happens similar to a power > outage at some point and the printer only partially installed. According to > Windows and the group policy management utilities the printers were > successfully installed, but all of the driver utilities didn't quite make it > causing > the Spooler to freak out. When something like this happens event log is almost > useless because it just tells you the prinint spooler crashed from an uknown > error. > Windows update seems to regularly stop working when a malformed update > package is downloaded. You would think it could just checksum it and delete > the package rather than failing to install it a few hundred times before a > user > complains that their workstation won't stop installing upates. I even had a > case > where a failed update created new registry keys every time it tried to install > and after a few months of not being able to do so the machine slowed to be > unusable. Roaming profiles is an absolute mess, and folder redirection Works > decently as long as you disable offline files on all of the clients. Otherwise > windows will just randomly decide that it can't connect to the server and only > show the users their offline files. > Windows deployment services on the other hand Works absolutely great and is > perfect to put fresh installs on the machines that died from various other > issues > with windows and / or malware. > This is starting to somewhat turn into a rant, and in all honesty for most > things > Windows does a pretty good job. Pretty much all the issues I outlined would > only affect people using Windows as a workstation OS. Embedded applications > generally don't have updates or network connectivity, and thus are probably > fine. > That being said my *nix machines have never given me an issue that wasn't > easily fixed since they were put in place. I almost forget about them > sometimes. > Sent from my T-Mobile 4G LTE Device > > -------- Original message -------- > From: Rod Smallwood <rodsmallwoo...@btinternet.com> > Date: 5/27/2016 5:37 PM (GMT-05:00) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk@classiccmp.org> > Subject: Re: Windows use in medical spaces (Re: vintage computers in active > use) > > > > On 27/05/2016 22:04, Ali wrote: > > > >> It makes me wonder how many patients have had to wait on care or > >> didn't get proper care because of an IT screwup related to Windows. I > >> have to say just _seeing_ Windows on machines in the ER made me > >> livid. I found it breathtaking they were that caviler about getting > >> people checked in, keeping records straight, etc... I guess I > >> shouldn't have visited the sausage factory, so to speak... > >> > >> Then again, folks in hospitals probably should be more concerned with > >> patients than with their IT tools. Ugh. Still. Windows? I'd have felt > >> better about paper forms. At least they don't blue screen. > > > > I would say very few. You have to remember critical systems are not > > running a general windows system i.e. people are not surfing the web > > on them and installing the latest games recommended by friends from > > facebook. Windows on its own is very stable. I.E. if you take a clean > > install of windows SW on recommended HW and just use the built in apps > > and never go on the internet it will run without any issues. Medical > > HW makers are basically using recommended HW, building one application > > on top of the OS, and test the hell out of it. Since they limit the HW, SW, > > and > modality of use it runs stable. > > > > Almost all (maybe 80%) of your medical HW is probably running some > > flavor of windows. > > > > Pyxis/Omnicell: Windows CE > > Sonosite: Windows 2K or XP > > EMRs: Windows XP or 7 (usually virtualized through Citrix). > > > > Heck DOS is still around too! > > > > The more specialized equipment (fluoro machines, MRI/CT, etc.) usually > > have their own OS although I am seeing C-Arms w/ windows back bones > > now a days as well. As the focus is going toward cost saving more and > > more generalized HW/SW is being used. After all why re-invent > > everything for each device when you can use windows to run the HW, > > network, input, etc. and just have the medical device (e.g. ultrasound > > probe) act like a peripheral with its own drivers. > > > > Where windows causes an issue for the hospital is in the general > > business areas (HR, accounting, administration, etc.). > > > > -Ali > > > Please can we have some specific instances of Windows causing problems. > Not unqualified people at home or students but real production environments > with qualified support on hand. > I used every version of windows from 1 to 10. yes XP and millennium too > > I wrote time and mission critical food distribution related software for the > ten > years before I retired in vb and then vb.net (oo) I would have seen just > about > every possible bug in windows and in developing applications under it. > > Lets hear what others experienced. > > Rod > >
