Adventures in administrative image land

[mp3-250]

so I have just deployed more than 100 workstations. It was the first time, without experience in scripting and I made a lot of mistakes... the biggest was to trust SOLIDWORKS.

- Documentation is poor and you have to figure everything by yourself.

- when launching the script in the pre and post processing keep in mind that user interaction is not allowed everything must be run silently and un elevated as the installer is already runnIng with administrative privileges

- batch language is bad

- configuration utility is garbage and require you put the setting file On a shared path. PDM edrawings and simulation must be configured via registry figuring out the keys using dozen of KB articles and a lot of trial and error. it seemed a good idea to take the sldreg as a base and write some other reg for pdm sim edrawings

BUT

- If you think to use the setting file that SW output as a reg file be very careful as some part is exported without escaping the "\" with "\\".
SW import the wrong sldreg it exported correctly so I ended up deploying 100 machines with a registry glitch that got accidentally unnoticed during the test phase making SW crash on a lot of comands. it took me one day to figure it out.
sldreg is supposedly reg4 (ansi or shiftJIS for us double byte characters junkies) while modern reg5 (UTF16LE)is not compatible and for us it is a pain on many levels.
solidworks do not use the sldreg strait, but it somehow check it and change it as needed.

- If you plan to overwrite the registry with the pre or post scripts be aware that SW installer is 32bit so you could end up writing the 32bit portion of the registry and SW would apparently skip your settings in HKLM. Took two weeks to figure it out.

- batch language is bad

- due to some internal regulations we ended up deploying the administrative on each C: drive. It is mentioned in a phrase in the manual and nothing more: it is possible but it has a lot of limitations. still very useful.

- pdm vault view creation does not work as per SW 2022. not a big problem anyway

- when using the automatic deployment you need one user common for each workstation that exists locally. the installation run as a task scheduler Task under SYSTEM user so it is not visible on a local user desktop (running in background)
We were forced to log in with every single user so I made a batch to automate remote desktop from an excel list of our machines user and pw

- batch language is bad

- after installing SW from an admin Image copied in C: it could be deleted still allowing the unistall process

- clean install (5.6gb SSD) took 15-20 min, while 45 min to upgrade
1h and half for HDD (we still have those leased machines).
it includes:
unistalling a third party software;
installing and configuring sw, pdm etc;
reinstall a third party software;
reboot the machine

- I made a script to synchronize the local admin image to the server copy if needed. very useful to patch things in the future. (thanks god I made it so tomorrow I am going to fix the registry mess)

Did I said that batch language is bad?
I should add that paired with asian languages is a suicide mission.

have a nice day, mine was spent to debug solidworks registry for the 100th time. it is 11PM and I want to go home.

[AlexLachance]

Ouch, 100 workstations, that must be hell.

[gerard]

We (my IT goober and I) have gone through this twice now. First time was for v2021. All seemed to be per the documentation and went smoothly.

Second time was for v2022. Much had changed, little/none of it documented, lot's of trial and error to get it going. Things we had cleaned up (like the hell bent insistence on putting material tables in a folder which need admin rights to access....) got unfixed in v2022. Oh, and the push tools we used in v2021 no longer worked properly. ITG had to log into each machine and run a script to do the upgrade.

Thanks Dassault....

[rodface]

For large deployments (I would say 50+ machines in a single location, 30+ machines if multiple sites) deployment/management tools like SCCM and an admin knowledgeable in their use, are worth their weight in gold. Other packaging solutions exist and likely perform similar tasks. The SLDIM built-in deployment tools look interesting but my feeling is that they would only work well for very small, very local deployments. I am sure there are admins who have used it successfully at large scale and I would be interested in hearing from them.

[Frederick_Law]

ITG had to log into each machine and run a script to do the upgrade.

Thanks Dassault....

Job security for IT.
Disruptive was built-in to SW since the beginning.

[Peter De Vlieger]

Knowing how utterly crap Solidworks is in providing any guidance that goes beyond explaining that clicking extrude function will let you extrude things and clicking cut will let you cut things...

Knowing that it's difficult if not impossible to find anyone in any department at Solidworks that actually knows and understand the nitty-gritty of any of their products because most likely the person who made a certain feature didn't document it and isn't working there anymore...

Reading things like this by people who were left carrying the proverbial can, having to figure out the actual steps all by themselves, and having been there myself concerning certain matters because hardly anyone understands the issues and those rare ones that do understand what the problem is can't provide a solution....

All this makes it really hard for me to advocate PDM for the small team(<10) at the company I work for.
Seeing that every year Solidworks becomes more and more like a pet project for marketing department bozo's to please some managers that earn their fat checks by cooing over flashy colors and features that sound great because it promises nurturing synergies that will incentivize B2B climate enhancements to uplift the workflow and create positive feedback ...... and other outright drivel similar to that.