Using Powershell Workflows to scan for Hyper-V instances in parallel

Here is a powershell script I’ve worked up to scan a network for Hyper-V hosts (or at least machines that have the Hyper-V port 2179 open).

It runs the tests in parallel using the foreach –Parallel option, and I decided to limit it to 32 threads, you can experiment with different numbers.

This will search everything on 192.168.X.X.  You can easily modify it for different ranges of IPs.

This must be run in a 64 bit mode, so if you are doing this through Powershell ISE, make sure it isn’t the x86 version.



workflow workflow1{
    $port = 2179

    $net = "192.168"

    $range = 1..254
    $netrange = 0..254
  
    foreach ($nr in $netrange)
    {
        $currentnet = "{0}.{1}" -F $net,$nr
        "scanning $currentnet.0"
        foreach -Parallel -ThrottleLimit 32 ($r in $range)
        {
			$ip = "{0}.{1}" -F $currentnet,$r

			if(Test-Connection -BufferSize 32 -Count 1 -Quiet -ComputerName $ip)
			{
				InlineScript{
					$ip = $using:ip
					$port = $using:port
					Try
					{
						 $socket = new-object System.Net.Sockets.TcpClient($ip, $port)
					}
					Catch{}

					If($socket.Connected)
					{

						".................. $ip is listening on port $port" 

						$socket.Close()
					}
				}
			}
         }
    }
 }

  
 workflow1
Advertisements

FLIR Cloud Client locks out accounts

Having wasted 6-8 hours of my life over the past month trying to figure out what the hell was going on with my new security cameras, I think I have finally found an answer, and it all comes down to shit software.

One can setup the FLIR security cameras via a web interface.  Among the first things I did was to change the default password from admin/admin to something else.  Later, when I tried to setup the FLIR Cloud Client software (some desktop application that lets you see all your cameras, record stuff etc), it would find my cameras, but they would fail to connect, even though I was SURE I was entering the password correctly.

After failing to connect, I’d go back to the web interface and find that my account was now locked out!

So I’d have to pull the power on the cameras (which meant a trip down to the basement) to force them to reboot and release the lock on the admin account.

After a ton of trial and error over many days, I finally discovered the issue:

The FLIR Cloud Client won’t work correctly with any password over 10 characters in length.

I shit you not.  The web interface works with 11 character passwords just fine.  The Cloud Client software also has no issue with accepting a 10+ character password (it doesn’t complain about it, or stop you from typing the 11th character), but somehow it mucks it up, and not only does it fail to login, but it must try over and over and over, thus instantly locking the account.

This is so frustrating because it has cost me so much time and because it’s only a shitty software product that would allow a situation like this.

For a “security company” I also found out that FLIR is almost certainly not storing users passwords correctly.  After signing up for their DDNS service, they sent me an email 10 minutes later with a bunch of information, including my password in clear text.  Aside from how horrible that is in and of itself is, this almost guarantees that users passwords are being stored in some way that is retrievable, meaning that I should basically assume that password is known by others.  Facepalm.

I hope this saves someone else all the time and frustration that I’ve gone through.

Problems deploying SQL database to Azure SQL

Today I tried to use SSMS to deploy a on prem database to SQL Azure.  I did this with Tasks->Deploy Database to Windows Azure SQL Database:

image

But at the end of the process I got this cryptic error:

Image

It reads:

A project which specifies Microsoft Azure SQL Database v12 as the target platform cannot be published to Microsoft Azure SQL Database

The issue was that the database server in Azure I was targeting was not running the most up to date version of SQL Azure. 

It’s easy to find out if you are running V12 on the server by looking at the icon:

image

Or you can follow these instructions from https://azure.microsoft.com/en-us/documentation/articles/sql-database-v12-whats-new/

Another technique to ascertain the version is to run the SELECT @@version; statement in your database, and view the results similar to:

  • 12.0.2000.10   (version V12)
  • 11.0.9228.18   (version V11)

A V12 database can be hosted only on a V12 logical server. And a V12 server can host only V12 databases.

If you are not yet running on V12, you can upgrade your logical server by following the steps in Upgrade to SQL Database V12 in place.

Here you can see the server shows itself as “V2”.  Clicking on the V2 gives you the Settings window which allows you to select “Latest SQL Database Update”, and finally “Upgrade this server”.

image

After that, everything worked!