Most IT departments use checklists for common tasks like deploying new workstations, on-boarding employees or new servers. It does not matter weather you on-board / deploy or you terminate / decommission a user or system. Checklist can be created for various tasks for assets like workstations, servers and equipment as well as employees.

You can create the similar lists – e.g. a list new accounting user / new manufacturing user – or – PC build (for preparing available systems with the default image) / PC deployment (for deploying and customizing the system when deployed to a user). In the end it is up to you how you use and engage those checklists, but they can be very powerful.

A checklist of course might not just be a simple list with instructions, it might collect data like version numbers, dates, etc. as well as having links to your intranet documentation about specific steps for a task to even executing scripts. All of this can be accomplished with the checklists. You can add a single title per item, additional instructions (item memo), define if the item is mandatory or not, define if it has a textbox to expect information from the employee that is executing the list, add additional links to e.g. intranet places like Exchange Web-Admin portal that can be clicked while working with the list, and even add scripts as cmd-scripts or PowerShell scripts that can be executed with a single button click and even retrieve information from the parent table/asset from the database.

To accomplish this, you first create a template and define to which asset type it belongs. Then you add checklist items – in a simple tabular form. Please pay attention to the green instructions text above this table that gives you hints on how to most effectively enter the items.

Use the preview checklist button to see how your checklist will look like.

Limitation: Please be aware that there is a limitation due to the way the checklist system works and Microsoft Access that only allows a certain maximum form height and width. A checklist can go over two columns, left and right – but once you filled it up – you might need to split it in two separate templates that both would need to be executed. You can limit the wasted space by transferring instructions in the Memo field that might be rather long to a local intranet and just use the links to point to them.

When you look at a checklist, you see that there are two columns of checkboxes at the left of each checklist item. The first column defines if it is applicable, this is checked by default, the second checkbox is to be checked once the item / task is finished – by the executing employee. By design – either both checkboxes need to be checked or unchecked – they can’t be different. If a entry becomes mandatory, the applicable checkbox can not be unchecked. Similar rules apply to the text-fields that can be added.

A checklist remains in progress until it is finished with the appropriate buttons in the top. It only can be finished if all necessary fields are checked / entered as defined in the template. Altering the template after a list was started / created will not alter the target list – in other words – if you e.g. create in workstations a checklist based on any template – this template will be copied completely as is – if you a few minutes or months later alter the template – the created list still will not change or be affected. There is a version control on those lists.

Only application users with the right to create templates can unlock a finished checklist, making it edible again. This avoids that your regular database users lock and unlock checklists as they like and give you some kind of certainty that the data wasn’t altered afterwards.

To further help with this task and determining when something was checked, unchecked, text entered or e.g. a button for a script clicked, the information will be saved as well in the database. If you hover of an item that was clicked somehow before – it will show you tool-tip-text with information who and when the field / button was clicked or data entered.

The biggest challenge might be the scripts – I do have some scripts active for e.g. removing Active Directory accounts or password database entries, as well as sending welcome emails. But all of this is so specific to each and every environment, that you really need to develop them yourself. Once they are working, they will become very powerful.

Checklists have additional SysConfig parameter for some control over the necessary rights, e.g. execute as a certain user or relative user (default user: jdoe / executing user: jdoe_admin – depending on logged on user, etc…). Please refer to the section in the manual for details.

Examples for scripts

Since there seems to be a lot of questions about script, I thought I post some example scripts here to keep you going. Please see below for more information.

DHCP reservations

Create this SQL server view in the database

And create the following script in your defined scripts folder

In this script, adjust this line to your preferred DHCP server – this could be a parameter as well, but in this example it is hard coded in the script.

$DHCPServer = “yourDHCPserver.domain.local”

Now add a checklist entry – the parameters should look similar to this – keep in mind – this is specifically for SERVERS and nothing else – otherwise adjust the SQL view to the table PRINTERS or WORKSTATIONS as needed.

  • Script
    • C:\IT Assets\ChecklistScripts\CreateDHCPReservation.ps1″ [!hostname!] [!domain!] [!MACAddress!] [!IPAddress!] [!IPNotation!]
  • Script-Type
    • ps1
  • AlternativeScriptSource
    • qryCheckListScriptServerMACIP

Remove DHCP reservation (retirement checklist)

SQL – we will use the same view we used for the DHCP reservation script – see above – if you have it already, you are all set. We now will create a second script

In this script, adjust this line to your preferred DHCP server – this could be a parameter as well, but in this example it is hard coded in the script.

$DHCPServer = “yourDHCPserver.domain.local”

Now add a checklist entry – the parameters should look similar to this – keep in mind – this is specifically for SERVERS and nothing else – otherwise adjust the SQL view to the table PRINTERS or WORKSTATIONS as needed.

  • Script
    • “C:\IT Assets\ChecklistScripts\RemoveDHCPReservation.ps1” [!IPAddress!] [!IPNotation!]
  • Script-Type
    • ps1
  • AlternativeScriptSource
    • qryCheckListScriptServerMACIP

Remove a server/workstation from Active Directory

  • Script
    • “C:\IT Assets\ChecklistScripts\RemoveWorkstationFromAD.ps1” [!hostname!]
  • Script-Type
    • ps1

This is a way simpler script as the DHCP reservation – but it works as well. Similar stuff can be done with adding systems to groups etc…