dpitcher wrote:
... I wonder if it would have been/is better practice to create a separate script to do all of the processing and creation and then just use the form script to collect and validate the data for processing and then call the processing and creation script.
While this sounds like a good idea it probably is not really what you want.
I have built many large multi-form projects over the years using almost all tools available on the Windows platform : Visual Studio (6-2012), PowerBuilder, SQLWindows, FoxPro, MSAccess, VBScript, WSF, HTA etc. I have built dozens of Windows Forms with: PowerShell (No Sapiens), PrimalForms, PowerShell Studio, PowerShell/WPF.
If we were to do task driven analysis we would come up with basic updates that are done regularly each requiring a different form. Even if we look at new user creation we see that it is a multi-step process. It can be driven into a workflow but that is likely to be over-kill for an admin task. For example we know that all account creation for employees should be driven from HRS documents and automated by the HRS department. The same is true for de-provisioning. This is the way most employee resources have been handled for decades. It is a direct fallout from the mainframe days.
Many of my clients have a mainframe HRS process that creates all of the employee’s bits including badges and insurance and any other records. The creation of NT accounts is either done by the mainframe HRS process or. In some places, it is done by a Scheduled Task or Windows Event that signifies the availability of a new employee record in a file or in a database. In one case this is actually triggered by an email with the employee ID in the email subject all other info is in a database.
If you have a very small company with only a few employees and no HRS department then the user creation may be left to the Admins. In this setting a PowerShell form can be very helpful. It can be an ongoing summary of all steps needed to create an employee.
Trying to use a creation form for updates may be a bit more difficult. You can just copy the form as a base from which to create a managed-task form.
On Windows Vista and later Microsoft has started using a full data form with little edit buttons to access system configuration information. This was started back with MSSQLServer 2005 I believe. These buttons are in logical groupings of the data and allow us to review all associated information on a scrollable form. These buttons then open up custom Wizards that handle the edit process. This allows for a very high degree of concentration and simplicity while providing access to a complex, rule driven update Wizard. It in no way matches the wizard used to initially set these values. This technique is very flexible and can actually use a rule engine to generate these forms. They in no way look like classic Windows Forms. The wizards are groups of simple dialogs that collect incremental and logically related bits r direct the editing of those bits. These are easy to build and maintain and can be easily updated when needed. Windows Forms require extensive program and forms management.
If you only have one or two updates a year then I recommend using ADUC by an experienced Admin. Tis will prevent you having to become a full time software developer just to edit a few employees. If you find yourself doing something repeatedly then create a custom tool. DO not get suckered into doing software development that you are not being paid for and that you are not trained to do. YOU job as an Admin will suffer and your company will not reward you for this. They will just assume it is a free part of system administration.
Admin tool building is a good idea but building complex systems requires good design and an environment that is conducive to managing custom code. Tis is why most companies have stopped doing internal software development.
PowerShell Studio is a very good tool. It can create very sophisticated projects with multiple forms. It can be used to build and maintain a toolbox as a single project. It has a good facility for creating templates. It does not have an enterprise debugger and it cannot easily do regression testing. This limits its usefulness as a software development tool as it is designed as a PowerShell script management tool.
I am not saying don’t attempt this. I am only showing you the things you need to consider before setting out on this path. What you ask can be done. It will not be an easy task if you have no prior software development training. Set out on this path with all of the above in mind.
Alex and David at Sapien may have some suggestions as to capabilities of PS Studio that I have not thought of. It will be interesting to see what they can add.
If you choose to build a large custom Admin tool set you should consider documenting your experience and posting it in a blog or web.
Statistics: Posted by jvierra — Sat Aug 10, 2013 11:53 am