With everything that happened with Facebook yesterday, I began to wonder where does my query goes when I type in facebook.com. So, I did a few things and found out. The first thing I did was resolve the name facebook.com to an IP address, or group of IP addresses in this case with the command resolve-dnsname.
Resolve-DnsName -Name facebook.com
Then from there, I used the site, ip-api.com to pull the location information of the IP address. This awesome little site gives you city, state, country, zip codes, and even the ISP information of an IP address.
$Info = Invoke-RestMethod -Method Get -URI "http://ip-api.com/json/$IP"
That’s the base of the code that we will explore. It’s very straightforward, but I want to clean it up some. I want to make a Get GEO IP information and a Resolve DNSname to Geo IP. I want it to all work together even if there is multiple IP addresses and hosts names. So, lets start off with the scripts and break them down. This will contain two functions for what we are wanting.
Get-SHDGeoIP
function Get-SHDGeoIP {
[cmdletbinding()]
param (
[parameter(Mandatory = $true)][ipaddress[]]$IPAddress,
[switch]$Complete
)
foreach ($IP in $IPAddress) {
$Info = Invoke-RestMethod -Method Get -URI "http://ip-api.com/json/$IP"
if ($Complete) {
$Info
}
else {
[pscustomobject]@{
IPAddress = $info.Query
City = $Info.city
State = $Info.regionName
Country = $Info.country
ISP = $Info.isp
}
}
}
}
This script is going to pull the geo information for us. We start off with the parameters. We are testing the parameters to see if the IP address is an valid IP address. We do that with [ipaddress]. This tests for both IPv4 and IPv6. We tell it to be a array of IPaddresses with the [] inside of it. [ipaddress[]]. Just for cleaner fun, I have a switch for a complete information dump. This way
Since this is an array of IP addresses, we will start a foreach loop for each IP address in the array. We start the foreach loop by grabbing the IP information. If the user selected complete, we just dump the information we gathered to the user. if they didn’t select complete, we create a custom object with the IP address, city, state, country and ISP information.
The next function uses the previous function and combines it with Resolve-DnsName. We start off with a list of strings for our hostname parameter and our complete parameter. We start our loop like before of the host names. Then we use the Get-SHDGeoIP -IPAddress command with the Resolve-DnsName -Name and the link name. We then select the IP addresses which is an array. We place that array inside the Get-SHDGeoIP and bam, we have our information. Converting a hostname like Facebook.com to IP information.
With these two little scripts, you will be able to find quick information about a website and where it is being hosted. For example, this site is hosted in new jersey. I personally didn’t know that.
WSD is an awesome service for printers. It goes out and finds a printer on the network and adds it accordingly. It does all the IP address stuff for you. Which is awesome. It even tells you that it was set up as a wsd by naming the port wsd and some code. Super friendly. However… What happens when DHCP changes that IP address because someone forgot to do a reservation? How do you get that IP address? Believe it or not, that IP address is stored in the registry for the most part. Its located under the Hardware Local Machine > System > Current Control Set > Enum > SWD > DAFWSDProvider. Each entry has a friendly name and location information. The location information has the IP address like a web page. Powershell can give you this information pretty quickly with a single line as well. Let’s take a look.
Get-childitem is normally used in directories. The registry is a type of directory with files inside of it. So we use the get-childitem and treat the registry as a file path. We navigate to the DAFWSDProvider. Then we look at each file or in this case item property with Get-ItemProperty. We are looking for that FriendlyName and the LocationInformation. The location information will look like https://192.168.2.62/something because it is treating the IP address as a webpage. Still unsure why. The above command will list all of the printers like this. If it has an IP address, it will appear there.
Now we can wrap this up in a nice little function for remote computers.
Passwords can be hard to make for people, especially kids and older users. That’s where Dino Passwords come into play. You can make simple and yet complex passwords using this service. This service also has a simple API to work with. I personally like using the API with new user creation scripts. The API is a single line with the invoke-webrequest command let.
This past week I needed to find all of the quickbook files on a computer without accessing quickbooks itself. The core of the script is a simple Get-Childitem command looped for each logical disk on the machine. Looking for one of the four main extensions for quickbooks. The four extensions are as follows
Since I want this to be a little easier to use, I broke it down between the file types with a validate set parameter. This way you can choose which extension you want. Then I go through each extension and make an if statement for each one matching up the extension.
Next we get the disks using the Get-CimInstance -classname win32_logicaldisk. This grabs all the mapped drives, local drives, and anything else that has a drive letter.
Now we loop through those disks and search the root of each drive for any files with the extension we choose. We select the fullname as this gives us the full path. I also like having file size and last write time to determine if the file is valid still. Once we go through this loop we display the information.
Improvements
I can add remote computers to this setup.
That’s it, if you have any questions feel free too reach out.
I have a love hate relationship with dell. When it comes to windows 10 upgrades, I really don’t like them. How do you mass push windows 10 upgrade to clients without breaking them. As many of you know, recently the 20H2 update has broken many different dells. So, a quick way to fix this is by comparing the model to the online list. This script isn’t that big, and is designed to be deployed from the end user’s machine as a system service or admin account.
The Script
$DellSite = Invoke-WebRequest -Uri "https://www.dell.com/support/kbdoc/en-us/000180684/dell-computers-tested-for-windows-10-october-2020-update-and-previous-versions-of-windows-10" -DisableKeepAlive
$Dellraw = $DellSite.Rawcontent.split('`r')
$CPInfo = Get-ComputerInfo
if ($Dellraw | select-string $CPInfo.csmodel) {
if (!(Test-Path "$($env:SystemDrive)\Temp\Win10Upgrade")) {New-Item c:\temp\win10upgrade -Type directory}
$DateTime = (Get-date).ToString("yyyy-MM-dd_hh-mm-ss")
$webClient = New-Object System.Net.WebClient
$url = 'https://go.microsoft.com/fwlink/?LinkID=799445'
$file = "$($env:SystemDrive)\Temp\win10upgrade\Win10Update_$DateTime.exe"
$webClient.DownloadFile($url, $file)
Start-Process -FilePath $file -ArgumentList '/auto Upgrade /quiet /noreboot'
} else {
Write-Error "$($env:COMPUTERNAME) is a $($CPInfo.CsModel) and is not on the approved list found at: https://www.dell.com/support/kbdoc/en-us/000180684/dell-computers-tested-for-windows-10-october-2020-update-and-previous-versions-of-windows-10"
}
The Breakdown
I’m glad you decided to stay for the breakdown. This breakdown isn’t going to take long. The first element of this break down is the invoke-webrequest. We capture the website with the required information. (Link). Then we split the raw content by the return carriage.
Now our web data is ready to pull from. Now we need to get information from the computer itself. Most systems these days have the Get-ComputerInfo command on them. It pulls the system info on a computer. Next, we ask a simple if-then statement. If the $DellRaw has the model number, then download and install the upgrade, if not let us know. Basically, we need a bouncer at this point. We use the $CPInfo.CSmodel as this is the model number.
$CPInfo = Get-ComputerInfo
if ($Dellraw | select-string $CPInfo.csmodel) {
#Install the upgrade
} else {
#Warning the installer program that it's not on the list.
}
The Download and Install
We first ask if the file folder is there. If it isn’t then we create it using the new-item command. Then we want to create a datetime stamp. Like in previous blogs, we use the .tostring() method to format the output. Then we declare the url and file path. Next, we invoke-webrequest command and download the file using the -outfile flag. Finally, we start the install with the correct flags. In this case, we want the install to be an upgrade that is silent and doesn’t force a restart because it could be in the middle of the day when this thing is finishing up. To start the installer we use the start-process
If your computer model is not on the list we will need to do a write-error. It’s best to say the computer name, model name, and the website it is pulling the data from. The write-error is collected by the standard deployment software.
Write-Error "$($env:COMPUTERNAME) is a $($CPInfo.CsModel) and is not on the approved list found at: https://www.dell.com/support/kbdoc/en-us/000180684/dell-computers-tested-for-windows-10-october-2020-update-and-previous-versions-of-windows-10"
I hope this helps. Y’all have a great day now you hear.
I don’t like working with Citrix receiver. They drive me crazy. One version doesn’t work with the other and so on and so forth. Then finding the one you need is a pain. Thankfully, the workspace is a little better at this process. Many of my clients have recently updated their back end so the new workspace will work for them. It only took a while. So, I built a script that automatically downloads the newest version and installs it accordingly. It wasn’t until later did I realize someone else did this already. But the one I made is a little better as it doesn’t run into the conflict of pulling the version number, at least in my humble opinion. This time we will start off with the script for us lazy admins. If you want to learn how it works, keep reading on.
Lets break this guy down. The first part is we are testing if the c:\temp folder exists. If it doesn’t then we will create it. Then we test if the Citrix folder exists, if it doesn’t, once again, we create it. We do this with the Test-Path for testing and the New-Item cmdlets.
IF (!(Test-Path c:\temp)){New-Item -Path c:\ -Name Temp -ItemType "directory"}
IF (!(Test-Path c:\temp\Citrix)) {New-Item -Path c:\temp -Name Citrix -ItemType "directory"}
Now we have the folders we will be using created, we need to move to creating the first log entry. We want this log to have a timestamp on it that matches the downloaded installer. To do this, we need to get the datetime first. While doing that we will create the filename of the log and the file name of the download path. This way it’s easier to work with later on in the script. We do this by using the Get-Date cmdlet. Normally the Get-Date cmdlet outputs is an object. Which isn’t very useful in a file name since it contains forbidden characters. (Not forbidden like slifer the sky dragon). A translation is required. We do this with the .tostring() method. Notice the way we format it.
We then use the $StartTime variable inside the log name and the download pathname. This is done by a string with the variable inside of it. Next will be to create the log. We do this with a simple > which means out and create. >> means out and append. Notice in the example below we $($StartTime) we do this because the next character is a :. Inside PowerShell, you can do things like $Global:Var which tells the shell to keep that var in memory for other functions to use. This means the : is a command character. This is why we wrap the start time variable inside a $(). Powershell will only print what is inside the $(). Finally, take note of the > $Logname. We will be using $Logname more inside this script. This is why we created the variable.
Now we have the start of the log. It’s time to get the installer. In the past, we would just go to the download link and add that to a download script. However, recently Citrix changed how they download. They have tacked on an additional piece of code. Everything past the GDA is that special code they have tacked on to stop direct downloading. However, we have PowerShell on our side.
The first thing we want to do is setup a try catch. This way we can catch errors and log them. Also we can break the script with an error message that is useful. This way if you are deploying out with something like continuum or PDQ your error message makes sense. Inside the try, we want to get the webpage itself. Then log that we grabbed information. The cmdlet to get the website is Invoke-webrequest. In the below example I am using the -usebasicparsing because it’s more compatible with websites and with systems. My goal is to launch this thing to 100+ machines. The -Uri is for the website itself and finally, we use the -sessionvariable as a websession. This allows us to grab data easier, especially if it’s auto-generated, like in this case.
After we grab the website, we have to log the event. We do the same thing we did with $StartTime and place it in the file we created a few moments ago.
If these commands fail for whatever reason, the website is down, the internet is blocking, anything, we need to know that the site can’t be reached. This is why we have a log. We create the same as the $logime but this time we also add a write-error and a break command. The write-error command will send an error to a deployment software, This way we know what’s going on. The break command breaks the script at that point and doesn’t continue.
$LogTime = (Get-date).tostring("yyyy:MM:dd-hh:mm:ss")
"Site: $($LogTime): Failed to access" >> $Logname
Write-Error "Site Error: Site not accessible"
Break
Lets put them together inside the try catch so you can see what it looks like.
Now we have the website itself inside a variable. It’s time to find what we need. The $CitrixPage contains different elements inside of it. Each item can give you information. The Rawcontent is just like it sounds, raw content of the page. While status code can give you information about if the site is up or what condition it is in. In this case, we will be looking at the links and status code. We check if the site has a good status of 200, if it doesn’t, then we don’t want to battle that battle. Thus we log and break like before. If it does, however, we want to take apart the links and find the one that contains the exe that we need. We do this with a where-object cmdlet. We search the .rel for the *CitrixWorkspaceApp.exe. Because the .links sometimes produces incomplete links, we have to build them. That’s the second step is to build the link. We will wrap the outcome inside an https: string.
if ($CitrixPage.statuscode -eq 200) {
$DownloadLink = $CitrixPage.Links | Where-Object {$_.rel -like "*CitrixWorkspaceApp.exe*"}
$URL = "Https:$($DownloadLink.rel)"
} else {
"Site: $($LogTime): Site Status Code $($CitrixPage.StatusCode)" >> $Logname
Write-Error "Site Error: Status Code $($CitrixPage.StatusCode)"
Break
}
Now we have the custom URL for the download, we need to download the file itself. Remember the $DownloadFullPath we created a while ago. It’s time to use it. We will be using the invoke-webrequest once again as well. This time we will use the -OutFile cmdlet. This cmdlet of invoke-webrequest will download the file as requested from the url provided. Of course, we want to wrap all of this inside of a try catch. This way we can log correctly and break as needed.
Now we have the installer to work with. The filename has the same time/date stamp as the log file so we can compare if the script doesn’t finish up correctly. Next we will start the process of another try catch to install the program. The command we will use is the Start-Process command. We start the $DownloadFullPath for the file name. We want this thing to be quiet and overwrite everything else there. Citrix, if given the /forceinstall will force the install by uninstalling the last version. Finally we tell it not to reboot with the /noreboot. Once we get past the arguments, we want to make sure we have the information from this thus we put the -passthru flag. This will allow us to store the information into a variable if we want to use that information later. The final part of the command is the -erroraction. We want this thing to stop if it hits an error. This way we know that something is broken. Then we log accordingly and catch accordingly like above.
We are almost done! This program takes an average of 5 minutes on older machines to install. Thus we sleep for 7 minutes. To do this we use the command Start-Sleep and set the -seconds to 420 seconds. We also make sure we log this information.
As we are not in a hurry, we use the PowerShell command Get-CimInstance to get the products and sort through that to find the Citrix Workplace Browser using the where-object cmdlet.
Finally we check to see if the install was successful or not. This is done with a simple $null -ne $something. We do it this way because we first load nothing and start to compare nothing to something. if something is there, then we know the statement is true and stop processing. Very simple concept. If $Citrix does contain something we log that the install was successful and remove the installer. If we find $Citrix is $null, then we log the error and error out once again.
With all good scripts, there is always room for improvement. The one that is blaring is the waiting for the install. This should really be a loop checking files or a registry key. If the file or key is not present, then continue to way 30 seconds. This would speed up the process as some computers process faster while others do not.
The second is the get-ciminstance because this is a slow command. We can improve the speed of this command by targeting once again either a file or a registry key instead. This way we can prove it was installed without the 30 to 60 second wait for the get-ciminstance to do its thing.
As always, If you have any questions, feel free to ask.
