Software for when requirements are not ‘set in stone’
As I have mentioned in a few blogs now, with over 1,500 commands, our FastTrack Scripting Host (FSH.EXE engine) is an extremely powerful and easy to use Network Scripting language. If something is not possible to do ‘out of the box’ using our GUI ‘builder’ app, it’s never too much of a challenge to script exactly the functionality you were looking for AND deploy it network wide, in an insanely short amount of time.
Do you need to make your users more… agreeable?
To prove my point, why don’t we look at the popular ‘Codes Of Conduct’ feature in our Logon Script wizard and then examine how we can use FastTrack Script to extend (more like totally transform) the functionality?
Tucked away in the ‘Alerts’ section > ‘User Alerts’ tab of our Logon script wizard is a ‘Codes of conduct’ configuration widget. Code Of Conduct is a handy configuration option that enables you to present your users with a ‘you have to read this to continue’ Code Of Conduct message. The message can be displayed either via a simple text dialogue box, or more styled content coming from a framed web page. Like anything in the builder, it’s instantly deploy-able company-wide, in just a few clicks.
Configuration options are as follows:
• Set the frequency (first logon only, every logon, daily, weekly or Monthly)
• Set the header text of the dialogue box / web-page box
• The URL of the web page to show
• Manually set custom window size (defaults to 600 x 500)
Recently a customer was interested in deploying this Code Of Conduct functionality across their network. After some testing however, they found that the feature fell far short of expectations. Yes it is a simple quick and easy to roll out, but in this case, far too simple.
Their feedback included questions such as:
- Rather than just a single ‘OK’ button, is it possible for us to add a YES / ON option here?
- If the user says NO, can then we force a log off?
- Can we record all the user YES/NO inputs?
- Can we also store the inputs so that a user doesn’t have to fill out / read the Codes Of Conduct message again if they have already accepted, even if they change computer?
- Can we have the main text web page box be full screen, whatever resolution on whatever device they are viewing the page on?
The customer had asked himself all these questions when navigating our Logon Script builder configuration wizard and came the conclusion that the answer was ‘NO’.
He then checked with me, and I told him the answer was most definitely a ‘YES!!!’.
I built a solution in a couple of hours. Let’s now go through each part of the script and post the final working script at the end.
If your name’s not down, you ARE coming in…
A major requirement for this script was to create a simple means to collect and store the details of those that answered YES to our YES/NO question. By storing the details of users that answered YES, we can ensure that these users would not need to be shown the terms again, regardless of what device they were using.
To do this we use our IniFile and IniValue commands. IniFile creates a structured text file, placed ideally on a user writable but hidden share on the network that users can write to. Once logged in the file, our script can parse it via the IniValue command, so we can use the result to apply conditional ‘tests’.
So the very first line of script is to call our IniFile so we can decide if the logged in user needs to run our Terms & Conditions script. We fire off a request to go to look for the UserName value in our IniFile, and wrap this line in an IF statement. So we are simply checking if a UserName is ‘on the list’.
'' FIRST WE CHECK IF THE INI FILE EXISTS, AND IF THE USER IS IN THERE If [IniValue \\ac10\Yotta\FT-Logs\Consent\consent-state.ini,Users,[UserName]] = "" Then ResumeOnError
Instead of IniFile/IniValue, we could have used XML or even our SQL commands, but we were looking for something low maintenance and simple, so our Ini commands were the right choice in this case. In addition to hosting the inifile on a hidden share, we could also use FastTracks script encryption feature to encrypt the entire script, so that anyone that came across the script file on NETLOGON, would not be able to see the path of the ini file.
For those that are logging in the first time, or did not accept the conditions last time, they will ‘fail’ the IniFile/Value check, and as such, they are forced into the main script.
The first thing they will see, is a brief GUI splash screen, the aim of which is to show our unsuspecting user that something ‘different’ is about to happen. We want to give the user a little advanced warning that they will shortly be shown some important text, and as such, they should put that coffee down, focus, and read carefully!
'' IF THEY ARE NOT IN THE INI FILE, THEY START THE SCRIPT - FIRST UP IS THE SPLASH SCREEN.... Splash Attention! You will now be shown the company codes of conduct, Read read carefully, \\ad10\NETLOGON\fshbin\ft-logo.png Sleep 10 RemoveSplash
Next we set a couple of variables, which we set based on the users existing screen width a height. We then invoke the ‘SetWindowSize’ command, but using it with the previously detected variable values.
'' THIS BIT WE ARE DETECTING THE RESOLUTION OF THE USER SCREEN SO WE CAN GENERATE A FULL SCREEN WEB PAGE LATER... Set MyScreenWidthVar = [ScreenWidth] Set MyScreenHeightVar = [ScreenHeight] SetWindowSize [ScreenWidth],[ScreenHeight] SetMenuHeaderIcon Exclamation SetCompanyLogo \\ad10\NETLOGON\fshbin\ft-logo.png
The result? Our Ts & Cs framed browser window is always shown full screen, rather than a fixed size. That’s a pretty neat trick!
Next we set the header icon (in this case, exclamation) and the company logo.
Now that pre-setup is done, we can show our Ts & Cs web page. For this example, I have borrowed Facebook’s very clean online Ts and Cs, but of course, you can use your own, be it internal or externally hosted. If the executing user can connect to it, they will see it. To proceed any further past this screen, the user has no option but to hit ‘OK’.
'' HERE WE CALL THE WEB PAGE - I USED FACEBOOKS AS AN EXAMPLE ShowWebPage https://investor.fb.com/corporate-governance/code-of-conduct/default.aspx, Code Of Conduct
So far so good.
Next we set a value for ‘SetAskTimeout’. This command turns a lazy ‘leave around forever’ YES/NO into a ‘need to make your mind up in 10 seconds’ YES/NO! The point being is that we need to put in a ‘non-committal’ default option. If someone doesn’t want to hit either YES or NO, we still need to time them out.
This is what SetAskTimeout does for us.
'' THIS IS WHERE WE SET THE TIMER COUNTDOWN. SetAskTimeout 10
Now this next bit required a little thought.
Because our ‘Ask’ command is ‘wired’ to set the ‘YES’ option to default (meaning that not clicking on anything would result in a forced YES) , we have turned the command into a negative and then switched the button labels around. Doing this means that the button marked NO now becomes the default option. If the user does nothing, can’t decide, or simply is so disgusted by what he or she has read they don’t feel obliged to click anything, NO is assumed, and well… you will see what happens!
We also inject the users display name from AD to make it appear a little more formal / contract like.
If the user clicks the YES button, they are then shown another personalised Splash screen and their login process continues.
'' THE BUSINESS PART. WE ARE ASKING IF THE USER (NAME TAKEN AS VARIABLE FROM AD) AGREES If Not Ask "I, [UserFullName] agree to consent to the company codes of conduct", Consent Notice, Screen, NO, YES Then '' THIS IS WHAT HAPPENS WHEN THE USER AGREES SmallSplash Thank you [UserFullName] - please wait whilst we log you in Sleep 2
In this YES block, we set our network located ini file ‘consent-state.ini’ with the values for username, and a date stamp.
'' HERE WE WRITE THE INI FILE WriteIni \\ac10\Yotta\FT-Logs\Consent\consent-state.ini,Users,[UserName],[DateTime]
We also write a CSV file specifically for those that accept, in which we include not only a date stamp of the acceptance, but also their computer name, IP address and whether the computer was a laptop or a desktop (Computer Type). We could also grab their employee ID if that was stored in an AD custom attribute.
'' HERE WE WRITE THE CSV FILE AppendFile \\ac10\Yotta\FT-Logs\Consent\yes-consent.csv,"[Date],[Time],[UserFullName],[ComputerName],[IPAddress],[ComputerType],Yes" Else
For the people that accepted, the script ends here, and thanks to the ini file, they will never run this script for this set of Ts & Cs again. They now proceed to complete login and can start work on their PCs.
If in the future a new set of Ts & Cs comes out, and everyone needs to re-agree, all that needs to be done to re-activate the script for those that previously agreed, is to delete the ini file. It will then be re-populated as people re-agree to the new terms. Very simple!
Finally, if you had different departments that needed different Ts & Cs scripts, you could use the ‘sub sites’ feature, defined by your conditions, so that each sub site had a different Ts & Cs script.
Accept this: No acceptance, no login!
For those that choose not to accept, well the outcome is rather different….
On hitting NO or nothing at all, we do not write the ini file, but we do write all the ‘NOs’ to a separate CSV file, which no doubt can be setup to be consumed by the evil dragons of HR!
'' THIS IS THE PART FOR THOSE THAT DON'T HIT A BUTTON, OR HIT NO AppendFile \\ac10\Yotta\FT-Logs\Consent\no-consent.csv,"[Date],[Time],[UserFullName],[ComputerName],[IPAddress],[ComputerType],No" ShowMessage "You did not agree to our terms and conditions. Please click OK to be logged out." Sleep 2
Shortly after, we present the user with a customised splash screen, informing them that as they did not accept the terms and conditions, they will be logged out. This screen uses the GUI box type of ‘menu’ which requires the user to hit OK. I have used it just to illustrate the different GUI menu box types, you can use another if you wish here.
On clicking OK, next down this fork of the script is the ‘Hasta la vista, you’re terminated’ LogOffForced command. This is quite a self-explanatory command and forces a log off. The ‘NO’ user will soon find themselves right back at the login screen. They have the option to re-login and this time accept. Or pack up and go home!
'' AFTER THEY HIT 'OK' ON THE PREVIOUS MESSAGE, THEY ARE LOGGED OUT LogoffForced End If End If
And that, in 24 lines of code, is how to make yourself a slightly better ‘Code Of Conduct’ system that what is on offer through or builder. The script ensures that your network users must read and agree to a message (whatever it is) if they are to be allowed to log in and start work.
“What do you mean you didn’t know that making Bouillabaisse in the company microwave is not allowed? You are logged in, aren’t you? So you must have read and agreed to the company Ts & Cs!? Well!?”