Don't shoot the messenger!...
PLC Pie Guy said:
...They have to do something, its their responsibility to their users! Don't just say, meh, Microsoft will fix it in a few weeks...As of now, there is no fix! Big applauds to Microsoft and Rockwell!...
git said:
...I am surprised that its taking so long, there are a lot of users out there using CCW and this is not the first time, this has happen before and I think this is the 3rd time, so shame on them for not having a plan in place ready to roll out.
I sense the frustration here in the thread, but I don't think they are dealing with this in a off-handed or couldn't care less manner? By my reading of the situation, the "plan" has already been implemented, as far as Rockwell are concerned, and probably as speedily as could be expected at such an elevated level. Don't forget that the Windows Security Updates are not just applied to fix or keep "our" specific user software going. It relates to many aspects of the running Operating System. Microsoft cannot simply rush to "fix" one discovered anomaly in many Security Updates without scoping it all out and then correcting it, and then testing it as best they can, and then releasing it. Rush it and possibly CCW now works but perhaps something else now doesn't? Cue rants on other software Forums. These things take a minimum amount of time. Early February for a correction release is good going by Microsoft's standards, in my book of experience.
On Rockwell's responsibilities...
I don't speak for Rockwell and how they address issues, but my best guess here is that on programming workstations with ISaGRAF based software products installed, Microsoft introduced "something" in their recent Windows Security Updates that messes with these products, which would otherwise function correctly without said Security Updates. More specifically, ISaGRAF relies heavily on Microsoft Visual Studio, and it is most likely that the updates affected this particular product. But that would just be my best guess here. As ISaGRAF, which is used in several different software products, is a subsidiary of Rockwell Automation, it is indeed their responsibility to manage the issue through to a resolution. Rockwell, I'm sure, having realized the issue with their software products, would then have contacted Microsoft to root cause the issue. Having done so, it most likely was found that the root cause was that the "something" Microsoft had introduced in the Security Updates (Jan 8th 2019) is a Microsoft anomaly, and that the affected ISaGRAF based products are indeed otherwise functioning correctly. If so, it would not be Rockwell's direct responsibility to address this OS issue. Their responsibility to their customers is to take up the issue with Microsoft, which they appear to have done. Rockwell cannot develop or release corrected Microsoft Windows Security Updates, as of course we know. In this particular case it is Microsoft's responsibility to resolve the issue. I'm sure Rockwell have made it very clear to them that it needs to be addressed post-haste. Hence the mention of early February for the next batch of Windows Security Updates which should correct the issue. While this is not near quick enough for many users, this timescale is arguably quick by Microsoft's standards. They are probably doing quite well to get them to resolve it this quickly.
Rockwell Automation said:
Important – The Rockwell Automation software products themselves are correct. Microsoft is aware of this anomaly and has plans for a correction to the security update patch.
PRODUCT IDENTIFICATION
The products affected by the installation of the identified Microsoft Windows Security Patches are:
ISaGRAF 4 Workbench
ISaGRAF 5 Workbench
AADvance Workbench (all versions)
FlexiSafe™ Workbench
CCW (Connected Components Workbench) when used with projects containing Micro800™ controllers
ISaGRAF 6 Workbench for application targeting ISaGRAF 5 Runtime
ISaGRAF 6 Workbench for application targeting vMonitor Runtime
This, unfortunately, is just one of many glitches that can go unnoticed or untested before a Windows Update is released. Microsoft are dealing with such issues, where other software developer's products are not working, on an ongoing basis. So one could point one's frustration at them solely, more so than at Rockwell? But, pointing it anywhere does little good in these situations, I feel. Knowing what is causing it and what will fix it, and when, is all we should concern ourselves with here.
All I would say for those not able to resolve this at present is sit tight. Not very comforting words when folks are under pressure to get the job done, I know. But I think it would be a further waste of your time trying to mitigate this on a daily basis (removing/blocking updates) and potentially creating further unwanted headaches as a result of messing with the OS Updates.
But wherever you decide to vent your frustrations, please, not at me! I am not Microsoft nor Rockwell! I am only expressing my viewpoint here on how I "think" it is being handled by Rockwell i.e. as best as can be expected at such a multi-OS elevated level.
While I notice Microsoft have a patch to prevent Windows 10 from reinstalling removed KB Updates after a system restart; I think, in this case, it might have served them better to provide a patch "roll-back" to revert affected systems to before this anomaly and disable Windows Updates for a defined period until after the corrected updates have been released. This would be simpler for users to implement and then get on with their day.
But by all means, continue to rant, if that is what is helping you to get through these frustrating days!
Regards,
George