Microsoft SQL Management Studio Connection Parameters

Connecting to an SQL server remotely is pretty easy but occasionally you might need some additional help, such as if your sql database uses a non standard port.  You have a couple of options for logging into your sql server but I'm going to cover 2 ways of connecting using the Database Engine login method.

As shown if you change the server type to Database Engine then you can put either the machine name or IP address (I have ipaddress because it's easy) with a comma then the port; if your database uses a NON-STANDARD Port (something other then 1443) make sure there are no spaces before or after the comma as shown above.  Set the Authentication method to SQL Server Authentication, put in your database username and password, then connect.

The second method is using the "Additional Connection Parameters".  You must have the database hostname or ip in the server name, then select options.

You will see a number of tabs that will be displayed and you want to select "Additional Connection Parameters" but be warned this is sent in clear text.

You can then put in your connection parameters in the box displayed above.  You can't just put in the connection string you do have to put in the server name or ip in the server name field on the login tab; once that is done the Connection string overrides the GUI settings.

below is a sample connection string:

SERVER=$IP,$PORT;USER=$DBUSER;PASSWORD=$DBPASSWORD

A successful connection will then be displayed in the Object Explorer as shown below.

Windows 10 and Idle Timeout

I had built a simple session management software with a C# login screen that saves the data to a google sheet, and I used the Windows task manager for controlling the launching of the session management login screen and the idle timeout. In windows 7 the idle timeout was more/less 15 minutes. For in-depth information about the windows idle state

https://docs.microsoft.com/en-us/windows/desktop/taskschd/task-idle-conditions

As defined in the Task Idle Condition

"In Windows 7, the Task Scheduler verifies that the computer is in an idle state every 15 minutes. Task Scheduler checks for an idle state using two criteria: user absence, and a lack of resource consumption. The user is considered absent if there is no keyboard or mouse input during this period of time. The computer is considered idle if all the processors and all the disks were idle for more than 90% of the last detection interval. (An exception would be for any presentation type application that sets the ES_DISPLAY_REQUIRED flag. This flag forces Task Schedule to not consider the system as being idle, regardless of user activity or resource consumption.)

In Windows 7, Task Scheduler considers a processor as idle even when low priority threads (thread priority < normal) execute.

In Windows 7, when the Task Scheduler detects that the computer is idle, the service waits only for user input to mark the end of the idle state."


The changes in the Task Scheduler in Windows 8/10

In Windows 8, Task Scheduler performs the same general user absence and resource consumption checks. However, Task Scheduler relies on the operating system power subsystem to detect user presence. By default, the user is considered absent after four minutes of no keyboard or mouse input. The resource consumption verification time is shortened to 10 minute intervals when the user is present. When the user is away, the verification time is shortened to 30 second intervals. Task Scheduler makes additional resource consumption checks for the following events:

• User presence state changed
• AC/DC power source changed
• Battery level changed (only when on batteries)

When any of the events above happens, Task Scheduler tests the computer for idleness since the last verification time. In practice, this means that Task Scheduler may declare the system as idle immediately after user absence is detected, if the other conditions have been met since the last verification time.

This is a big problem for the session management system we had. It went from having a 15 minute idle check to 30 seconds to 5 minutes (varies as per above technical info)

So I wrote a program in C# that had checked the last time a user had used the system. This thinking was also flawed because like the Windows 8/10 idle check it was based on the last user input. What I wanted was a full 15 minutes after the idle program was launched. So I used this bit of code.

(DateTime.UtcNow - Process.GetCurrentProcess().StartTime.ToUniversalTime()).TotalMilliseconds

This is different because I had the program doing the idle reboot based on the following:

IdleTime = System.Environment.TickCount - LastInput.dwTime;

In my testing I would have the task scheduler launch the app but because I was checking for LastInput.dwTime I would have used up between 200000 and 400000 milliseconds, even though the app was launched on idle from the task scheduler. This makes total scene since I am reading the system event.  However I still want to use this code because I am using it to exit the application if the idle timeout launches the application for the countdown.  When the user comes back and moves the mouse or presses the keyboard it closes (exits) the application.

The major part of the code is as follows


using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Runtime.InteropServices;

using System.Windows;

using System.Diagnostics;

using System.Windows.Forms;


namespace EndSession

{


public partial class EndSession : Form

{

//initialize variables
//Popup Counter. This ensures we only see the message windows that popups in the last 2 minutes once.

int popupCounter = 0;



[DllImport("user32.dll")]

public static extern Boolean GetLastInputInfo(ref tagLASTINPUTINFO plii);




public struct tagLASTINPUTINFO

{

public uint cbSize;

public Int32 dwTime;

}


public EndSession()

{

InitializeComponent();

//Hide the windows for the program so no one can see it running.  Turn off for debugging

this.WindowState = FormWindowState.Minimized;

this.ShowInTaskbar = false;


}



private void timer1_Tick(object sender, EventArgs e)

{

tagLASTINPUTINFO LastInput = new tagLASTINPUTINFO();

Int32 IdleTime;

LastInput.cbSize = (uint)Marshal.SizeOf(LastInput);

LastInput.dwTime = 0;

if (GetLastInputInfo(ref LastInput))

{

IdleTime = System.Environment.TickCount - LastInput.dwTime;


//DEBUGGING Text Field

// label1.Text = IdleTime + " ms " + rowCounter + "run time:" + "last input" + LastInput.dwTime + "App start" + ((DateTime.UtcNow - Process.GetCurrentProcess().StartTime.ToUniversalTime()).TotalMilliseconds);

// label1.Text = idleStart +" "+ idleEnd;


}


IdleTime = System.Environment.TickCount - LastInput.dwTime;



//Check the idle time. If less then 100ms close the application.  Based on the last time there was user input
//The Reason for 100ms is if it is set to 0, the program doesn't always catch the user input. If it is set to high the program closes right away.

if (IdleTime <= 100)

{

//If the user had moved the mouse or hit the keyboard close the program because IdleTime is less the 100 milliseconds.
Application.Exit();

}


//This is our time check. If we were to use the system idle time the program would close at the time the

//user stopped the keyboard/mouse input We are starting the idletime based on when our app lauches

if ((DateTime.UtcNow - Process.GetCurrentProcess().StartTime.ToUniversalTime()).TotalMilliseconds > 780000)


{

if (popupCounter == 0)

{

//increment our popup counter and show our message box. Force it to main focus over all other windows

//MessageBoxOptions 0x40000

popupCounter++;

DialogResult AutoResult = MessageBox.Show("This System will reboot in 2 minutes if it is left idle", "End Session Alert", MessageBoxButtons.OK, MessageBoxIcon.Warning,

MessageBoxDefaultButton.Button1, (MessageBoxOptions)0x40000);

}


}

//If it is 900000ms or 15 minutes and greater since the launch or the app, force close all programs and restart.

if ((DateTime.UtcNow - Process.GetCurrentProcess().StartTime.ToUniversalTime()).TotalMilliseconds > 900000)

{

// Force close and reboot the system it is over 15 minutes or 900000 milliseconds

System.Diagnostics.Process.Start("shutdown.exe", "-r -f -t 0");

}

}


}

}


You can get the code from my GitHub Repository

 

https://github.com/scarletspider/idletimeout

How to bypass Java MD5 Security Setting to Run Java iKVM Viewers

You can view a video of the post on my youtube page.
A bit of background: Oracle issued a critical patch to Java in April 2017, JAR files signed using MD5 will no longer be considered as signed by the Oracle JRE. Affected MD5-signed JAR files were no longer be considered trusted and as a result will not be able to run by default, such as in the case of Java applets or Web Start applications.  Now this basically affects any iKVM managers for servers by Supermicro, Lenovo, or any vendor that shipped a remote console that uses java.  By default if you try run these redirected consoles you will be denied.  The fix for this is pretty simple but requires you to bypass disabling the MD5 filter.   You can find out more about this change here.

Please note this post assumes you have a 64 bit version of Java Installed.

Use notepad or a text editor (I prefer sublime text) and run the program as Administrator

Open the file C:\Program Files\Java\$JAVA_VERSION\lib\security\java.secuirty as shown below

You will need to edit the around line 615, I recommend copy and pasting the line and removing the MD5 from the jdk.jar.disabledAlgorithms as shown below then save the file.

Then you will need to open the JAVA Control Panel and whitelist the DNS Name or IP Address (I typically use IP Address) so that we can run the Java Applet.  Enable Java content for browser and Web Start Applications, change the security level to high and and the server to the Exception List as shown below.

Then you will be able to run iKVM java applets from your severs so you can manage them.  You will still get a couple popup prompts about running the Java applets, but after accepting them you will be able to run it.

Then you can manage your server as though you were sitting right in front of it.

You can view a video of this blog post here

Managing vPro Systems

When you are a sysadm in a small shop for about 100 machines for 2 locations your find efficiencies to make your job easier.  I had an idea for using VPRO as a remote IT support solution.  I know vpro has it's issues such as being proprietary and there are solutions such as remote assistance, remote desktop, and teamviewer to name a few why would I use vpro?  

Well when you use remote desktop it blocks out the screen of the user your trying to help; remote assistance isn't the easiest process to use, and teamviewer users get confused with the ID and the username and password part of the teamviewer UI.  With VPro this is secured to an internal intranet network this allows me to turn machines on when I need to do work on those systems remotely, do remote support, see any issues they are having with any software where logs don't provide enough detail' and I can see the bios boot and logs if required.  I know vpro has it flaws and a number of major security issues lately but it does make my life easier with being able to remotely configure the system, check logs and even make changes to the bios without physically being there (unless someone unplugs the network cable).

Meshcommander

First you need to make sure that the vpro system is provisioned and you have set a username and password to access the vpro system.

To that end that's why I use meshcommander it is open source, works with vpro and I have 2 different ways of using the software.  The current version of meshcommander uses everything in a built in UI.  It is nice and easy to use but disconnects more then I like, probably because it is all browser based.

Meshcommander UI and System List

Mesh Commander offers a simple single UI where you can remotely manage all your VPRO based systems.  It's all integrated and easy to use.  Pro or Con you can only use one system at a time.

The other part which is depreciated by the same project is the Manageability Commander Tool.  This is kind of the piece meal solution before Mesh Commander.  The Manageability Commander Tool allows you to specify a VNC client for the connection.  I use Ultra VNC Viewer.

Mesh Commander Tools gives you a tab based interface.  Useful if you want to work in multiple windows.  For here you can launch the vpro management and access it from the browser.

The Mesh Commander Tool tab Remote Control allows you to specify how you want to connect.  You configure the remote desktop viewer to the VNC Viewer you want to use by browsing to the executable on your system.

You can specify which VNC client you would like to use.  UVNC viewer I have found works really well and you don't have to pay for any licencing which you have to for VNC Viewer.

Mesh Commander Tools Launches the VNC Program in a separate window and you can have multiple windows open at once which you can't with Mesh Commander