Converting from VMDK to VHD(X)
-
@NetworkNerd said:
Thanks for that. We were looking at potentially using Disk2VHD and using that to create a VHD for XP Mode for our Autocad software. That would allow us to have our Engineers stop operating one PC for Solidworks and one for Autocad.
Wait what? We have Solidworks and Autocad coexisting nicely on current x64 bit systems (the older x32 systems didn't handle it very well). What version of Autocad are you using?
-
@coliver said:
@NetworkNerd said:
Thanks for that. We were looking at potentially using Disk2VHD and using that to create a VHD for XP Mode for our Autocad software. That would allow us to have our Engineers stop operating one PC for Solidworks and one for Autocad.
Wait what? We have Solidworks and Autocad coexisting nicely on current x64 bit systems (the older x32 systems didn't handle it very well). What version of Autocad are you using?
I was hoping no one would ask about the Autocad version. It's Autocad 2000. It has been customized so much over the years by our Engineering team (using VBA), and it's not been a priority to get to a newer version that will run on 7 or better.
-
@NetworkNerd said:
@coliver said:
@NetworkNerd said:
Thanks for that. We were looking at potentially using Disk2VHD and using that to create a VHD for XP Mode for our Autocad software. That would allow us to have our Engineers stop operating one PC for Solidworks and one for Autocad.
Wait what? We have Solidworks and Autocad coexisting nicely on current x64 bit systems (the older x32 systems didn't handle it very well). What version of Autocad are you using?
I was hoping no one would ask about the Autocad version. It's Autocad 2000. It has been customized so much over the years by our Engineering team (using VBA), and it's not been a priority to get to a newer version that will run on 7 or better.
Oh, sorry. I was going to say we are running Autocad 2004 for the same reason but haven't had any issues running it on 7 (or 8.1). Good luck getting on to a newer version. I know how much engineers like their tools the way they are.
-
Forcing people to stay current is probably one of the greatest parts of a subscription based software package - I see all sides, but since I work on the IT and support side, I REALLY like this aspect.
-
@Dashrender said:
Forcing people to stay current is probably one of the greatest parts of a subscription based software package - I see all sides, but since I work on the IT and support side, I REALLY like this aspect.
Me too, that is huge. Forcing the business people into keeping software up to date is a huge win for IT.
-
@scottalanmiller said:
Forcing the business people into keeping software up to date is a huge win for IT.
I agree in principle, but have some.... concerns....
Merely the latest example:
https://isc.sans.edu/forums/diary/Reboot+Wednesday+Yesterdays+Patch+Tuesday+Aftermath/16556/ -
@MattSpeller said:
@scottalanmiller said:
Forcing the business people into keeping software up to date is a huge win for IT.
I agree in principle, but have some.... concerns....
Merely the latest example:
https://isc.sans.edu/forums/diary/Reboot+Wednesday+Yesterdays+Patch+Tuesday+Aftermath/16556/The latest version is not the same as the latest patches. I agree from a business perspective I'd like the ability to set my own deployment schedule, and if I'm large enough (which I'm not) to have test groups of users to deploy patches to.
-
@Dashrender said:
@MattSpeller said:
@scottalanmiller said:
Forcing the business people into keeping software up to date is a huge win for IT.
I agree in principle, but have some.... concerns....
Merely the latest example:
https://isc.sans.edu/forums/diary/Reboot+Wednesday+Yesterdays+Patch+Tuesday+Aftermath/16556/The latest version is not the same as the latest patches. I agree from a business perspective I'd like the ability to set my own deployment schedule, and if I'm large enough (which I'm not) to have test groups of users to deploy patches to.
In some ways I agree with that, big companies need some control of schedules. But in other ways I do not. It depends on the software, the use, and many other factors, but in some ways it is like moving to a DevOps model and the people who know best about when to roll out changes are the Devs who should rarely be questioned. Once the ecosystem is all completely up to date using rolling patches works really well. It is only when you run old software that you commonly need to keep running old software. In many ways, it is a problem that solves itself.
-
@scottalanmiller, I agree with your point, but the problem with that is the fragility of our environments. No two environments are the same. The frequent problems recently from MS patches shows that no enough testing is happening to keep these problems from causing huge pains.
-
I think that that is becoming less and less true. Quirky environments are becoming less and less the norm. The need to install locally is rapidly going away. There are still things that get installed locally but the variety and commonality is dropping at a prodigious pace and the isolation of programs is getting to be quite good.
