See What’s New in PDQ Deploy 12

Posted on 1 CommentPosted in PDQ Deploy

The beta for PDQ Deploy 12 is now available. To access the beta, make sure you have beta notifications enabled in Preferences > Auto Update Alerts. (Auto Update Alerts will soon be renamed to simply, Alerts.)

New in the PDQ Deploy 12 Release

Use PDQ Inventory Scan User Credentials in PDQ Deploy

Use the scan user credentials from PDQ Inventory (in Enterprise mode) for your deployment credentials in PDQ Deploy. In previous versions of PDQ Deploy you were limited to using one set of credentials for all target computers per deployment. This meant that computers that required different Deploy User credentials had to be broken down into different deployments. That all changes in PDQ Deploy 12. This new feature requires you to have PDQ Inventory 11.2 or higher and PDQ Deploy 12 both in Enterprise mode. When you create or schedule a deployment, under the options tab you can select to use the PDQ Inventory scan user credentials first, if available. If the target does not exist in PDQ Inventory, the default PDQ Deploy credentials will be used instead.

Wake-on-LAN/Ping Settings Are More Versatile

The Offline Settings have, historically, been global. We have now made it so you can modify your Offline Settings at the Package and Deployment / Schedule levels. In addition to your current global settings (found in File > Preferences > Deployments), you can now ping targets or send Wake-on-LAN (WOL) per package, Auto Deployment package, schedule, or deployment. For example you could have your global settings to only deploy to computers that are online (PDQ Deploy pings the targets and only deploys to the computers that respond) but change a particular deployment to override that setting and attempt to use WOL (Wake-ON-LAN) for the offline computers.

To ping a target or send a WOL per package (including Auto Deployment package):

Package > Properties > Offline Settings

 

To ping a target or send a WOL for a schedule:

Schedule > Offline Settings

 

 

Some Improvements…

Post Schedule Notifications

If you are already a fan of using Post Deployment Notifications, you will enjoy this addition. You can now set Post Schedule Notifications to send only one email upon deployment completion of the entire schedule rather than multiple emails when using a Post Deployment Notification. You also have more options for customizing your emails and can now use variables in the subject line and email body. Set up a Post Schedule Notification very similarly to a Post Deployment Notification in File > Preferences > Mail Server.

You can add additional custom variables to use in notification emails (and other areas in PDQ Deploy) in File > Preferences > Variables.

post-deployment-notification

Nested Package Run As Options

When adding a nested package, you can now select to use the Run As option of the nested package. You can change this setting by selecting the nested step and going to the Options tab.

run-as-options-for-nested-packages




Initiating Deployments and Scans Using PowerShell

Posted on Leave a commentPosted in PDQ Deploy, PowerShell, Scanning

Utilizing the CLI interface (available in both PDQ Deploy and PDQ Inventory) we showed you initiating deployments and scans using PowerShell in this webcast. Why use the CLI? There are a few scenarios this can be handy, such as if you are on a remote computer and cannot access the console. Perhaps you want to script out something with scheduled tasks.

You may want to refer to this post from our webcast on preparing your environment for remote PowerShell.

Below are the PowerShell scripts, examples, and other files used in the webcast. Join our next webcast live, sign up for email notifications here

Webcast Bonus Content: Initiating Deployments and Scans Using PowerShell

How to: Enable TCP for Background Service

XML Imports

PDQ Deploy Package-Example Package

PDQ Deploy Schedule-The One  Schedule

Task Schedules – PDQ McTask

PowerShell Scripts

PDQ Deploy – Remotely initiating deployments.ps1

PDQ Inventory – Remotely Trigger a Scan

Reg File

Background Service – Enable TCP on port 7777.reg


Remotely Activate Office: Defending Against Mayhem and Horror

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy

It is the nature of things that seemingly straightforward recipes such as those to remotely activate Office can sometimes fail. Realizing that your 14,783 deployments of Office didn’t activate correctly and that 14,783 ravenous, ill-tempered, and thirsty (assume for blood) users will be walking into the office in less than twelve hours to face the Microsoft Activation Wizard, you need protection from the great unwashed mob, spray tanned, clad in cheap polyester ties and pencil skirts spilling forth from their Philistine fingers a Biblical flood of helpdesk tickets filled with recipes for your demise and foul language expressed IN ALL CAPS WHAT IS THIS WIZARD S___ AND WHY ARE YOU STILL EMPLOYED??? THE WEBSITE IS DOWN! DIE! DIE! DIE!, & etc…

office activation bad

What to do?

There are options beyond unplugging your phone and hanging dreamcatchers from your monitors to capture evil spirits and the results of horse-leavings. First, it’s assumed you’ve done a test deployment to a few machines, logged in to confirm Office was installed, opened Word to see if it’s the real deal or if it exists only in some purgatorial reduced functionality mode. Most importantly, do you get the Activation Wizard?

If you do get the Activation Wizard, there is help. This help assumes you’ve entered the correct KMS or MAK keys in the OCT.

Using the Office Customization Tool (OCT)

First, open the MSP file you created with the Office Customization Tool (OCT) and navigate to the Add installations and run programs section. You’ll want to add the following target:

 %WINDIR%\System32\cscript.exe

Arguments, based on architecture and Office bitness*:

Office 2016:

"%ProgramFiles(x86)%\Microsoft Office\Office16\ospp.vbs" /act
"%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /act

Office 2013

"%ProgramFiles(x86)%\Microsoft Office\Office15\ospp.vbs" /act
"%ProgramFiles%\Microsoft Office\Office15\ospp.vbs" /act 

Office 2010:

"%ProgramFiles(x86)%\Microsoft Office\Office14\ospp.vbs" /act
"%ProgramFiles%\Microsoft Office\Office14\ospp.vbs" /act

OCT wizard

 

Like other things within the OCT, sometimes this doesn’t work. This is why we recommend testing. Each environment is different, and each deployment interacts with those environmental differences differently.

Remotely Activate Office without the OCT

If the OCT option doesn’t work, you can add these steps at the end of your deployment in PDQ Deploy to remotely activate Office (depending on architecture and Office bitness*):

remotely activate office

A note of some importance: if your Office deployment is one of those twee Click-to-Run products (C2R), there’s no Activation Wizard, so whew; the user signs in like anything else on the internet. Unless you’ve done some dark magic with Azure Active Directory, but that’s beyond the scope of this article. The AUTOACTIVATE element for Office 365 ProPlus is not necessary since activation is already automatic. For Visio and Project C2R products, you can use AUTOACTIVATE Value=”1″ to activate those products.

Checking the Activation Status of Office

If you’re curious about the activation status of your Office deployment but don’t want to login to a representative sample of end-user computers to test, you can run the tests safely from within PDQ Deploy.

For example, the following will return the activation status of the Office install. You should change the Program Files  and OfficeXX directory to correspond to the bitness of Office/Windows and the version of Office (2010 – 2016).

%windir%\system32\cscript.exe "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /dstatus

activate04

Some of the results you can get back from the Output.log of the deployment are:

Office Professional Plus 2016, unlicensed (and of course, not ACTIVATED):
LICENSE DESCRIPTION: Office 16, RETAIL(MAK) channel
LICENSE STATUS:  —NOTIFICATIONS—
ERROR CODE: 0xC004F009
ERROR DESCRIPTION: The Software Licensing Service reported that the grace period expired.

Office 365 Professional Plus 2016. Licensed and therefore ACTIVATED:
LICENSE DESCRIPTION: Office 16, TIMEBASED_SUB channel
LICENSE STATUS:  —LICENSED—
ERROR CODE: 0x4004FC04 (for information purposes only as the status is licensed)

Office 2016 Professional Plus (KMS). Installed, but NOT ACTIVATED (running in the grace period):
LICENSE DESCRIPTION: Office 16, VOLUME_KMSCLIENT channel
LICENSE STATUS:  —OOB_GRACE—
ERROR CODE: 0x4004F00C

Office Professional Plus 2016, licensed (and ACTIVATED):
LICENSE DESCRIPTION: Office 16, RETAIL(MAK) channel
LICENSE STATUS:  —LICENSED—

 

*Unless your users are rocket scientists that do all their orbital mechanics calculations in Excel, you probably don’t need (or want) 64-bit Office. If you can’t think of a concrete technical reason you need 64-bit Office, 32-bit is what you want.



See Also:
Active Directory-based Office Activation
The ospp.vbs Script
Methods of activating Office 2013


Silently Installing TightVNC 2.8.5 To Your Windows Computers

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy

If you have access to the PDQ Deploy Package Library you can use our pre-built package for silently installing TightVNC to all of your Windows computers. If you’d like to build your own TightVNC package you can follow the steps outlined below. In fact, building this package is an excellent exercise for learning how to build complex packages.  It is assumed that you have PDQ Deploy version 10 or higher running in Pro or Enterprise mode.

In this example we are only going to deploy the TightVNC “Server” portion. TightVNC is broken down into two components: Server and Viewer. There really is no need to deploy the Viewer to all of your computers unless you expect your end users to remotely control other computers. Since we only want the ability to initiate a remote control session against our target computers we will only need to install the Server portion.

Silently Installing TightVNC: Building the Deployment Package

You will want to download the TightVNC Installers (64-bit and 32-bit depending on your targets). In this exercise we are using the .msi installer files. Copy these files to an appropriate location. In our example we are placing these files in our PDQ Deploy Repository folder.

Open PDQ Deploy and create a new package. Add the following steps. Please note that these steps won’t necessarily match the exact steps in our TightVNC package that is available in the Package Library.

Package Steps

Step 1 – Create a Command step. This step contains one line. It stops any existing TightVNC Service.

net stop tvnserver

Set the Success Codes to 0,2 (Error code two is returned if the services doesn’t exist or is already started). You want to count these occurrences as a success.

Under the Options tab set the Error Mode to Continue.

Step 2 – Create a Command step. This will uninstall old TightVNC that wasn’t installed with an MSI. This is important so that you don’t have two versions of TightVNC installed. The MSI will upgrade existing TightVNC installations that were also installed via MSI. Type in the command below into the Command field of the Details tab.

"%ProgramFiles%\TightVNC\unins000.exe" /VERYSILENT

Go to the Conditions tab. Expand the File condition. Click the Exists radio button. In the directory field type in %ProgramFiles%\TightVNC and in the Filename field enter unins000.exe. By doing this you are ensuring that you only will run this step if the unins000.exe file is found in the designated directory.

Step 3 – Create a Command Step. This step will be identical to Step 2 except we are going to account for previous 32-bit TightVNC installations (non-MSI) that were installed on 64-bit targets. You will need to use the following command:

"%ProgramFiles(x86)%\TightVNC\unins000.exe" /VERYSILENT

Also, make sure to add the file condition like you did in Step 2 but use the %ProgramFiles(x86)% variable instead. Also, in the Conditions tab change the O/S Architecture to 64-bit. The images below show the contents of the Details and Conditions tabs.

blog-tightvnc-step3details

blog-tightvnc-step3conditions

Add Install Files

Step 4 – Create an Install step. In this step we run the 32-bit installer on 32-bit systems only. In the Install File field navigate to the 32-bit TightVNC MSI file.

Now, the parameters are extremely important for this step. You need to determine which parameters are important to your environment. I will provide the basics but you may want to tweak these a little. You can find the available parameters in the documentation. Below are the parameters we provide with our TightVNC package.

ADDLOCAL="Server" SERVER_REGISTER_AS_SERVICE=1 SERVER_ADD_FIREWALL_EXCEPTION=1 SERVER_ALLOW_SAS=1 SET_USEVNCAUTHENTICATION=1 VALUE_OF_USEVNCAUTHENTICATION=1 SET_PASSWORD=1 VALUE_OF_PASSWORD=helpdesk

Notice that we are setting the password value. You will want to pass this HOWEVER we have seen some instances where this value is not honored. We get around this in a later step by running a PowerShell script that forces the password change on the target. In this example we are setting the password to the word “helpdesk” without quotes. Please note that TightVNC passwords can only have up to eight characters. More appropriately, only the first eight characters of a provided password will be used.

In the Conditions tab set the O/S Architecture to 32-bit.

Step 5 – Create an Install step for 64-bit targets. Use the same parameters supplied in the previous step. Just change the O/S Architecture condition to 64-bit and, obviously, change the Install File to the 64-bit installer.

Finishing TightVNC Setup

Step 6 – We recommend placing a Sleep step here. The Sleep step is used when you want to pause a deployment for a certain number of seconds. Don’t go too crazy, 5 seconds should be enough.

Step 7 – Stop the TightVNC Service. A simple Command step can be used. Just run the following command:

net stop tvnserver

Don’t forget to set the Success Codes to 0,2.

Step 8 – Install DFMirage Driver (OPTIONAL) –  If you want to deploy the mirage driver to your computers then this would be a good time to do it. Create an Install Step. You can grab the install from the TightVNC download link mentioned before Step 1. Just a few notes. Make sure you don’t install the driver more than once on a target. We will show you how to prevent this. Also, according to the documentation the driver is compatible on OSes from XP – Windows 7. As a result we recommend using the O/S condition on this Install Step. Only include the appropriate OSes.

Please note on the Conditions tab that we (in addition to excluding later OSes) also have a File condition. We simply look for the file unins000.exe in the path %PROGRAMFILES%\DemoForge\Mirage Driver for TightVNC. Check the Does Not Exist radio button. This is one way you can prevent this step from installing the driver again.

The parameters we used to make the driver install silently are:

/VERYSILENT /NORESTART /LOG=.\output.log

Here is a screenshot of the Details tab on the Install Step.

Silently Installing TightVNC blog-tightvncstep8dfmiragedetails

Here is the Conditions tab for the same step.

blog-tightvncstep8dfmirage

Setting the TightVNC Password

Step 9 – Set TightVNC password. Create an Install Step. (You could also use a PowerShell step but we’ll just show you the Install Step method here)  {{Download this file: tightvnc-password-fix}}.  Kris Powell, our PowerShell rock star, wrote this script. We use this script because the password parameters in the install steps don’t consistently set the password for TightVNC. The parameters you will need to use for the script.

-Password "NewPassword" -Force

Step 10 – Create a Command Step. This step will simply start the TightVNC service. The following command should do the trick. Set the Success Codes to 0,1056,1058.

sc start tvnserver

There you go. Don’t forget that you can initiate VNC remote control sessions from within PDQ Inventory.




Silently Change Firefox Default Search Engine

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy, PowerShell

Oh, Yahoo! when will you learn you can’t buy friends? Firefox set the default search engine to Yahoo! back in 2014. Since then sys admins have been battling the forced setting. Looking to silently change Firefox default search engine in your network? Can do.

Changing search engines on an individual basis is simple. To make the change on your own home computer read this. If you manage a network of computers, read on.

Silently Change Firefox Default Search Engine

PDQ Deploy Package LibraryPDQ Deploy has a ready-to-deploy, silently installing deployment that will change the Firefox search engine to Google for all your users. In PDQ Deploy, go to the Package Library and import Mozilla Firefox – Set Google as Search Engine. Send this package to any of your target Windows computers that have Mozilla Firefox installed. Upon reboot, your users will have Google set as their browsers. You can choose targets from Active Directory, PDQ Inventory, Spiceworks, etc. How do I use the Package Library?

But let’s break down what’s in the package.

Using PowerShell – Silently Change Firefox Default Search

The package uses the following PowerShell script to make the change. This PowerShell script is provided by the illustrious Kris Powell. (Check out his PowerShell blogs.) This script updates all user profiles on the target computer, if a Firefox profile folder exists for a user. Your users will see the change after they restart their Firefox browser.

Param(
  [string]$SearchProvider="Google"
)

$disclaimer = "By modifying this file, I agree that I am doing so only within Firefox itself, using official, user-driven search engine selection processes, and in a way which does not circumvent user consent. I acknowledge that any attempt to change this file from outside of Firefox is a malicious act, and will be responded to accordingly."
$Pattern    = "{`"\[global\]`"\:{`"current`"\:`"(.*)`",`"hash`"\:`"(.*)`"}}"
$Encoding   = [System.Text.Encoding]::UTF8
$Hasher     = New-Object ([System.Security.Cryptography.SHA256]::Create())

Get-ChildItem -Path "$env:public\..\*\AppData\Roaming\Mozilla\Firefox\Profiles\*" | Where-Object { $_.PSIsContainer } | ForEach-Object {

    $result = [System.Convert]::ToBase64String($Hasher.ComputeHash($Encoding.GetBytes($_.Name + $SearchProvider + $disclaimer)))
    $File   = "$($_.FullName)\search-metadata.json"
    $Data   = "{`"[global]`":{`"current`":`"$SearchProvider`",`"hash`":`"$result`"}}"
    $SearchJsonMozlz4 = "$($_.FullName)\search.json.mozlz4"

    If (-Not (Test-Path $File)) {New-Item -Path $file -ItemType file}

    (Get-Content $File) | Foreach-Object {
        If ($_ | Select-String -Pattern $Pattern) { 
            $_ -replace $Pattern, $Data
        } else {
            $data 
        } 
    } | out-file $File -Encoding utf8
   
   If ((Get-Content $File) -eq $Null) {
        $Data | Out-file $File -Encoding utf8
    }
    If (Test-path $SearchJsonMozlz4) {Remove-Item $SearchJsonMozlz4 -Force}
}

What if I Want Something Other Than Google?

You can use any installed search provider as a value to update. By default in the US-version of Firefox, these values include:

  • Amazon.com
  • Bing
  • DuckDuckGo
  • Google
  • Twitter
  • Wikipedia (en)
  • Yahoo

Put your choice of search engine in place of Google. (Images below show the script in a PowerShell step within PDQ Deploy)

powershell change firefox default
The script (as it currently is written) supports a $SearchProvider parameter with a default value.  You can change script every time or just change the parameter when calling the script. Changing both is not required.

firefox search engine powershell

If you used the package from the Package Library, you would simply open up the imported package and edit the parameter field to your desired search engine.

silently change Firefox default search engine




Deploying to Computers Frozen with Deep Freeze

Posted on Leave a commentPosted in PDQ Deploy, Schedules

The problem: A machine in a frozen state loses all changes made to it at its next reboot. This is great for keeping machines in a consistent state for each user every day in, for example, lab environments. However, when the machine does not come out of a frozen state during a maintenance window, changes to software managed by PDQ Deploy are lost the next time it reboots. This can cause inconsistencies in lab environments and wreak havoc on reporting. How do you go about deploying to computers frozen with Deep Freeze? How can you keep your changes from reboot to reboot?

Faronics has produced a nice utility to allow for Command Line management of the Deep Freeze agent on client machines. When used with PDQ Deploy this shifts responsibility of controlling state away from Deep Freeze Tasks to the PDQ Deploy console itself.

Deploying to Computers Frozen with Deep Freeze

Step 1: Grab yourself a copy of DFC.exe.

You can get this from the downloads section of Faronic’s website, but if not you can reach out to their support and they will provide you with a copy. According to the Deep Freeze comparison chart DFC is available in Deep Freeze Enterprise and Cloud. It is not offered in the Standard versions.

Step 2: Configure an RDX file to enable Command Line access

You’ll want to edit a current one or create a new RDX file. On the passwords tab click Enable on one of the entries, change Type to Command Line, and provide a password. The password is alphanumeric and does not support special characters.

rdx-config-example-1

Step 3. Save and update your configuration on your target machines.

Step 4. Deploy DFC.exe to your lab computers.

For this I created a simple Package that includes 1 file copy step. I placed a copy of DFC.exe in my PDQ Deploy repository and set the deployment to “Push”. The target directory is C:\windows\system32. You could use C:\windows\SysWoW64, or any other directory that is in the target’s PATH. This will make things a little easier in a further step.

NOTE: You’ll want to go into Deep Freeze and THAW the machines you are deploying this package to so that the copied file will actually be there upon subsequent reboots.

Creating Your Deployment

Step 5. Create deployments wrapped around DFC

In this example, we will use the Auto Deployment package 7-Zip which is available from the Package Library. If you don’t have access to the Package Library due to your license level, or simply wish to do this with another package, the process is the same, so just follow along modifying the package(s) that you care about. The only slight difference you will see is that with Auto Deployments things go into the Pre and Post Deployment steps, so it looks different from a normal package, but is functionally identical.

Deploying to Computers Frozen with Deep Freeze

You can download an XML of this example deployment by clicking here. Here’s a rundown of what’s included in the pre and post deployment steps:

Pre-Deployment

Command Step containing:

dfc.exe <yourpassword> /THAWNEXTBOOT

Add a Reboot Step. This allows the PDQRunner service to control the next package steps, and the machine will be thawed to the DFC command you ran in Step 1.

Post-Deployment

Command Step containing:

dfc.exe <yourpassword> /FREEZENEXTBOOT

Add another Reboot Step which will cause the machine to be Frozen after the step completes, and the deployment will show as successful.




What’s New in PDQ Inventory 11

Posted on Leave a commentPosted in PDQ Inventory

PDQ Inventory 11 is now available! Want to try out the latest release? You can do so by clicking the “A new version is available” notice in the status bar of your console. If the update link is not visible, go to File > Preferences > Alerts; this will alert you to all future versions available.

What’s New in PDQ Inventory 11

Tools Librarytools-library

What is the Tools Library? Imagine an arsenal of ready-made tools for your IT department’s world domination plans. More tools are coming in later releases of PDQ Inventory, so you’ll want to jump in and get a hold of these tools now. The Tools Library is available with a current Enterprise license.

You can access the Tools Library in the left tree and then click the Tools Library tab to start importing your tools. Once imported, you can start using the tools on your computers by selecting any computer(s) and selecting the tool from the tools drop down.

tools-library

 

You’re definitely not limited to what’s listed in Tools. With a Pro license you can create your own tools, integrate tools (such as Sysinternals and DameWare), and create neat automation to easily execute. You might recognize this feature as the previously named “Custom Tools”. Custom Tools are now simply referred to as Tools instead of being listed in Preferences can now be found in the main console tree. Click here to check out some ideas for tools you can create. Into PowerShell? You should be. We hosted Stephen Valdinger, a PDQ Inventory customer, at a live webcast were he shared some of his favorite tools he uses in his environment. Click here to check out that webcast and glean some inspiration!

Nifty Updates and Upgrades

Remote Command Window

The remote command window you know and love has gotten a face lift…but the changes aren’t all purely cosmetic. Get a gander at the remote command window by selecting a computer (or computers), right click > Tools > Remote Command

  • Improved Command History – Delete individual commands in your history instead of having to clear the whole history. Save your favorites!
  • Scan After – Run a scan after executing your remote command, making it easier to keep your data in PDQ Inventory up-to-date.

New Columns in Files and Registry

You can now see which Scan Profile(s) returned the data found in the Files and Registry sections of a computers window. (Double-click on any computer, and then select either Files or Registry in the left panel to view the data.)

registryandfilesscanprofiles Pdq inventory 11

 




Keep Computers from Going to Sleep During Installation

Posted on Leave a commentPosted in Uncategorized

If you have an aggressive power savings plan, then you may have had issues with deployments failing due to a computer taking a nap mid-installation. Perhaps you have large install files that take a longer time to copy or install. While there are a few different ways to keep computers from going to sleep (GPO settings, WOL packets) let’s cover an option for keeping computers awake during a particular deployment.

Keep Computers from Going to Sleep

Meet Don’t Sleep. Don’t Sleep is a utility you can add to your deployments to keep computers from going to sleep. Run this as a command step before the rest of your package steps.

    1. Create a command step and add the Don’t Sleep exe in the Files field.
    2. Add the following command:
    3. Start "" DontSleep -bg enable=1 use_timer=1 set_timer=60

      The parameter set_timer is in minutes so feel free to adjust that to whatever time you need a computer to stay on for. Click here to see the full list of parameters provided

      dont-sleep-package


    4. That’s it! Add additional steps after the first step to do whatever installation or maintenance your little heart desires. Alternatively, you could take an already existing package and add this step. Just make sure that you click and drag it up to the top so that it runs very first.



Prepare Your Environment for Remote PowerShell

Posted on Leave a commentPosted in PowerShell

If you joined us at our live webcast this last Thursday (October 13, 2016 as of this posting) you were introduced to some nifty PowerShell scripts which we want to make available to you. If you missed the webcast, click the video below and get caught up! First, we discuss getting your environment ready for using remote PowerShell, then we dive into favorite scripts.

Don’t miss another free webcast by signing up for email notices here.

Preparing Your Environment for Remote PowerShell

Enabling WinRM

Usually, it’s easiest to configure WinRM with Active Directory Group Policy, but for those who wish to do it manually, these commands will help configure your machines to use WinRM by using either command prompt or PowerShell:

Command prompt or PowerShell:

winrm quickconfig -force -q

PowerShell only:

Enable-PSRemoting -Force

This will only setup the basic configuration for WinRM. If you want to take it a step further and secure it with a certificate, you could use this wonderful gem as a starting point: enable WinRM using a certificate.

Auto Login

Sometimes we have a need to have a machine automatically login with a specific user when the machine boots up. These scripts will help get that configured. Please note that each script includes a line that will reboot the target machine.

Setting up Auto Login for a Machine

Removing Auto Login for a Machine

Resolving Trust Relationship Issues

We’ve all been there. You have a domain trust relationship issue. There are many reasons for this to fail, but it seems that the most common has to do with the machine account password. Check out these scripts to get it working again.
Fixing the secure channel with Test-ComputerSecureChannel
$Credential = Get-Credential
Test-ComputerSecureChannel -Repair -Credential $Credential
Fixing the machine account password with Reset-ComputerMachinePassword
Reset-ComputerMachinePassword

Fixing Windows Update Service

If you’ve ever encountered an instance of the Windows Update service not running, this (very) simple script is for you. When using products that lock a machine’s settings (Deep Freeze, etc), we’ve noticed that the Windows Update service doesn’t always get set to run. This quick script will change the Windows Update service to startup Automatically and then start the service.
Set Windows Update service to Automatic and start the service
Set-Service -Name wuauserv -StartupType Automatic
Start-Service -Name wuauserv

Delete and/or Copy Files

These are just quick script examples for deleting or copying files.

Deleting temp files for current and all users

Copying files to all user paths

Getting IP Configuration Settings

Sometimes we just need a quick way to grab network adapter settings for a machine. Here are a couple of examples to do it for a machine. The first example can be used in a PDQ Deploy package or via a PDQ Inventory Remote Command. These ensure that a command is run locally on a target machine.  The second example could be used from a PDQ Inventory Custom Tool or even straight up from a PowerShell window (fancy).

Getting network adapter info locally

Getting network adapter info using Invoke-Command

Links Referenced in the Webcast

Definitely check out Stephen Valdinger’s blog on automating software installs for imaged computers.

Awesome PowerShell Commands List

Using PowerShell to Set Static and DHCP IP Addresses

Information on Microsoft easy fixes

 


Integrate Your Favorite Sys Admin Utilities with PDQ Inventory

Posted on Leave a commentPosted in PDQ Inventory

I was visiting a customer last month in Philadelphia and I really liked the first question that he asked me: “What feature do you wish more people would use in PDQ?”

“That’s easy. For PDQ Deploy it is Auto Deployments and for PDQ Inventory it is Custom Tools.”

Those of you who know PDQ Inventory are probably familiar with the Tools menu. The Tools menu allows you to call fairly common tools/utilities with a few keystrokes. The image below shows the default tools that come with PDQ Inventory. You can initiate VNC or Remote Desktop sessions, deploy software via PDQ Deploy, view the Event Log on the target and so on.

DefaultToolsMenu

You can also add your own tools or utilities. Now it is up to you to extend this list to include your favorite sys admin tools and utilities. Basically, if you have a program/utility that can called from the Command Line (CLI) then you can integrate it with PDQ Inventory. Here are some of my favorite examples:

Example Integrations with PDQ Inventory

DameWare Remote Control

If you use DameWare for your Remote Control solution then you owe it to yourself to create a custom tool to initiate DameWare remote control sessions. You can see a breakdown of the available DameWare commands here.

In my environment I have DameWare 12. It is installed on the computer where PDQ Inventory runs. You may differ slightly in your command depending on where DameWare is installed and what options you want to use, but here’s an example.

Go to File > Preferences. Select Custom Tools. Click the New Tool button. Give the new tool a name. Your command may be different depending on your DameWare path and how you authenticate (Smart Card, Windows password, etc.).

"C:\Program Files\SolarWinds\DameWare Mini Remote Control x64\DWRCC.exe" -c -h -m:%TARGET% -md: -a:1 -x:

You can also add the shortcut keys CTRL+SHIFT+D. The shortcut is optional.

DamewareCustomTool

 

Here is a quick breakdown of the DameWare CLI.

 -c means “Connect Automatically”.

The -m: argument expects you pass the name of the target computer. Well, we don’t want to hardcode a computer name here because we expect to run this command against many different computers. This is where we can use a variable. In this case I am using the name of the computer.

How did I know which variables were available? Well, surprise surprise, I referenced the documentation. From the Custom Computer Tool window I simply clicked the help button (the blue question mark). I could also simply hit the F1 button. If you don’t have this window opened you can also just jump to the online help for this feature here. You will see a list of the variables that we support. As far as the rest of the command arguments refer to the DameWare link above.

Now when you are looking at a specific computer in PDQ Inventory you can initiate a remote control session by selecting Tools > DameWare 12 or using the shortcut you defined.

Open an Elevated CMD Window

If you use UAC then you’ve probably had to re-open a CMD window after you realized it wasn’t running in an elevated mode. Here is how you can quickly open up an elevated CMD window.

Create a custom tool. Call it something like CMD (Elevated).

In the Command Line field enter the following text:

%SYSTEMROOT%\system32\cmd.exe /k

Notice how no variables are being passed? This is intended. I just want to open a cmd window. In cases like this you should enable the System Tool checkbox. This means that you don’t have to have a computer selected in PDQ Inventory in order to run this custom tool.

CustomToolCMDElevated

 

Open Active Directory Users and Computers

Here is how I open up the Active Directory Users and Computers window. This command is actually a snap in called dsa.msc and it is loaded into the Microsoft Management Console (MMC). As a result you won’t call the actual dsa.msc file but instead pass the this file as an argument to mmc.exe. Obviously you need to have the Remote Server Administration Tools (RSAT) enabled on your console machine before you can run this command.

%WINDIR%\System32\mmc.exe dsa.msc

CustomTools-DSA

 

As you can see the process is fairly simple. You may need to do some leg work to find the correct command line to run, but the effort is well worth the work.