I have been tasked with providing a solution for a "break glass" audit mechanism within RDM. I've created a powershell script that provides a graphical interface that prompts the user for information (ticket number, description, etc), validates and updates the ticket, injects the information into the session log file, then proceeds to log the technician into the session.
Since the powershell event does not have a "Wait for exit" option, I've compiled it into an executable and use the following command line event on the template.
myexecutable.exe -RDMSession $SESSION_ID$ -RDMName $NAME$
All works as expected except when the user decides to cancel. I cant seem to identify a way to prevent the session from continuing to login the user after the script has exited. I've tried a number of things. I've tried using Close-RDMSession on the cancel button event and while this does close the powershell session, it continues to open a new template session (without completing the validation requirement).
Is there some other way to prevent the session from continuing? I've been staring at this problem too long and need some thoughts outside of my box.
I've also noticed that the Get-RDMOpenedSession will hang while the script is executing. As soon as the script is exited, Get-RDMOpenedSession completes.
Wow, nice implementation.
Sadly, we do not have a way to stop the process, that would be a good improvement. Something like looking at the process exit code...
I have looked for a solution that would work with our existing code base. The first solution that came to mind was to use our "custom credentials" type. This is in fact a powershell script that should get credentials from some other system (we created this to interface with Microsoft LAPS)
I thought that if the result of your validation isnt right, you simply return wrong credentials and the launch would fail. Sadly there is a limitation that would force us to store credentials that are not encrypted, its most likely not acceptable for you. That is, unless you have a secure storage system that you can access with powershell...
I will ask around to see if others have ideas. Most likely David will also look at this as a feature request, maybe we could implement something quickly.
Just let me know if you want to pursue my idea, its not perfect but I'll let you be the judge of the pros and cons that are specific to you.
My POC script below. Remember it goes in the custom credentials object
Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing
$form = New-Object System.Windows.Forms.Form
$form.Text = "Data Entry Form"
$form.Size = New-Object System.Drawing.Size(300,200)
$form.StartPosition = "CenterScreen"
$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Point(75,120)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = "OK"
$OKButton.DialogResult = [System.Windows.Forms.DialogResult]::OK
$form.AcceptButton = $OKButton
$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Point(150,120)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = "Cancel"
$CancelButton.DialogResult = [System.Windows.Forms.DialogResult]::Cancel
$form.CancelButton = $CancelButton
$label = New-Object System.Windows.Forms.Label
$label.Location = New-Object System.Drawing.Point(10,20)
$label.Size = New-Object System.Drawing.Size(280,20)
$label.Text = "Please enter the information in the space below:"
$textBox = New-Object System.Windows.Forms.TextBox
$textBox.Location = New-Object System.Drawing.Point(10,40)
$textBox.Size = New-Object System.Drawing.Size(260,20)
$form.Topmost = $True
$resultM = $form.ShowDialog()
if ($resultM -eq [System.Windows.Forms.DialogResult]::OK)
$x = $textBox.Text
if ($x -eq "555")
$Result.Username = $PARAMETER1$
$Result.Password = $PARAMETER2$
Thanks for the quick reply! Unfortunately, I've already been down that road with the audit team... it didn't end well for me. I haven't given up just yet but there are times to pick your battles (in particular... with the audit team). I do really like the custom credential concept and will see what I can come up with. If there is a possibility of an enhancement request, that would be ideal.
In the meantime, I thought I had come up with a solution using a command line template and calling the Open-RDMQuickconnect cmdlet using the -TemplateID of the corresponding session template. I ran into a bit of a snag with this as well. Having the RDM option 'allow multiple instances' enabled, it works... albeit opening up a new instance of RDM and requiring app authentication. Disabling the 'allow multiple instances' has provided a number of different results. Most times nothing happens (can reproduce manually using the embedded RDM Cmdlet tool) and other times it opens a separate grey window with no menus or toolbars even though the template states embedded.
Using a template to call another template is a bit redundant but better than building a new session every time. I'm going to try the script on other systems to see if the Open-QuickConnect issue is specific to this 2012 box. I really need some workaround in the short term... using quickconnect "should" work?
Indeed the quickconnect should work, we havent had reports by our community that it stopped working.
I will discuss this with David at the earliest opportunity.
thank you for your patience.