I am working on porting a large VBScript tool to PowerShell, and I am running into some issues. My tool is a deployment and customization tool for Autodesk software, which is consistently not Windows standard when it comes to deployment and management. The tool involves a large number of Tasks, which can then be organized into Packages, and a large office could easily have 20-30 different packages that they have to manage.
My first question involves data structures. The VBScript version of the tool defined tasks using dictionaries in a separate Definitions.vbs file, but for the PowerShell version I want to move the definitions to a dedicated text file, either a simple TXT file or perhaps XML (but that really will require a GUI front end as my users are not going to be interested in editing XML directly). In either case, it seems like I have two choices for the actual data structure. I could push everything into Dictionaries, or I could make Objects of each. The program flow is to look at a package definition and break it into individual tasks, then proceed through the subtasks that make up that task.
As an example, the TXT version of a task definition and sub-definitions might look like this.
DefinitionID: RVT_2014 DefinitionType: “Rollout” ProductID: “RVT2014” Install: “\\dalfs\deploy\Autodesk\2014\Deployments\Revit2014\Img\Revit2014.ini” AddEnvironmentVariable: "ADSKFLEX_LICENSE_FILE | @dallic01;@atllic01;@tamlic01" CopyRevitINI: "RVT2014 | \\dalfs\revit\2014\Support Files\DAL-INI\Revit.ini" SeedUDC: "RVT2014 | \\dalfs\revit\2014\Support Files\DAL-UDC" InstallNetworkAddins: "2014 | \\dalfs\revit\2014\Support Files\DAL-ADDINS" ConfigRevitServer: "2014 | \\dalfs\revit\2014\Support Files\ALL-RS\RSN.ini" UpdateADSKMatLib: "2014 | \\dalfs\revit\2014\Support Files\ALL-MAT" Delete: "C:\msdia80.dll"
My question is, does PowerShell offer some data structure that is obviously best for this? Or is a Dictionary/Hashtable as I had in VBScript going to be as good as any other? If I can use this excercise as an excuse to also learn a bit more OOP thinking I would love to, but only if it is also the best solution for the tool.
My second question is regarding access to the tool. The tool has an Admin component and a User component, and in VBScript I used stub scripts to access things. An Admin package stub script would live on the network, along with the main script, and would include the package definition. You would run the package stub you needed manually, or via SCCM, and the admin script would then copy the user stub script to Program Files on the machine, and add that now local script to the Local Machine Run regkey. When the user logs in the script runs, and looks to see what user side tasks need to be applied.
That said, this approach looks like it won’t work in PowerShell as PowerShell modules on the network seem to be problematic. I have experimented with simple shortcuts that pass the appropriate package as an argument, but creating those shortcuts is fussy. I could do that programmatically, but I wonder if there is a better approach I am missing? I know PowerShell is designed as a command line tool, so I am an edge case here. And the usual choice of a UI is not viable for me either, as I have to be able to run the script via SCCM as well, which I believe won’t work with shortcuts.
I know this is a pretty large pair of questions, and that the answers may be in the form of just pointing a direction. Indeed, I am open to getting pointed at a PowerShell guru to hire for some consulting if need be.
Thanks! And Happy Holidays!
Gordon