28 March 2013

Setting Acrobat and Reader to autoupdate

Here is a powershell script I wrote that adds the registry keys for both reader and acrobat to make them automatically update. This is intended for admins to deploy out to all users in a firm. It doesn't hurt to add both keys, even if you only have one of the two apps. Here is the Powershell script:

You can download the script from here

 #*******************************************************************************  
 #   Author: Mick Pletcher  
 #    Date: 27 March 2013  
 #  
 #   Program: Adobe Reader Automatic Update  
 #*******************************************************************************  
 Clear-Host  
 $Global:OS  
 Function GetOSArchitecture{  
      $Global:OS=Get-WMIObject win32_operatingsystem  
      $Global:OS.OSArchitecture  
 }  
 GetOSArchitecture  
 If($Global.OS.OSArchitecture -ne "32-bit"){  
      New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Adobe" -Name "Adobe ARM" –Force  
      New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Adobe\Adobe ARM" -Name 1.0 –Force  
      New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Adobe\Adobe ARM\1.0" -Name ARM –Force  
      New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Adobe\Adobe ARM\1.0\ARM" -Name iCheck -Value 3 -PropertyType DWORD  
      New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Adobe\Adobe ARM\1.0\ARM" -Name iCheckReader -Value 3 -PropertyType DWORD  
 } else{  
      New-Item -Path "HKLM:\SOFTWARE\Adobe" -Name "Adobe ARM" –Force  
      New-Item -Path "HKLM:\SOFTWARE\Adobe\Adobe ARM" -Name 1.0 –Force  
      New-Item -Path "HKLM:\SOFTWARE\Adobe\Adobe ARM\1.0" -Name ARM –Force  
      New-ItemProperty -Path "HKLM:\SOFTWARE\Adobe\Adobe ARM\1.0\ARM" -Name iCheck -Value 3 -PropertyType DWORD  
      New-ItemProperty -Path "HKLM:\SOFTWARE\Adobe\Adobe ARM\1.0\ARM" -Name iCheckReader -Value 3 -PropertyType DWORD  
 }  

27 March 2013

How to run a Powershell script as administrator

Say you are deploying a package and need to run it as admin with elevated privileges. Of course if you are running the script manually, you can open up powershell with admin priviledges by running the cmd.exe as administrator. I haven't been able to find any easy ways of doing this within Powershell scripts, although it can be done. There is an easy way though if you use VBScript as a Powershell wrapper. Create the VBScript and point it to execute the Powershell script as admin. Here is how:


 Set oShell = CreateObject("Shell.Application")  
 oShell.ShellExecute "powershell", "-executionpolicy bypass -file test.ps1", "", "runas", 1  

That is all that is to it. Execute the VBScript and the Powershell script will be executed as administrator.

25 March 2013

Powershell: WMIC Product headers

If you are trying to query a list of installed applications using WMIC and want to only display certain headers, here is the list of header available:

wmic product get <header>

  • Node
  • AssignmentType
  • Caption
  • Description
  • HelpLink
  • HelpTelephone
  • IdentifyingNumber
  • InstallDate
  • InstallDate2
  • InstallLocation
  • InstallSource
  • InstallState
  • Language
  • LocalPackage
  • Name
  • PackageCache
  • PackageCode
  • PackageName
  • ProductID
  • RegCompany
  • RegOwner
  • SKUNumber
  • Transforms
  • URLInfoAbout
  • URLUpdateInfo
  • Vendor
  • Version
  • WordCount

SCCM: Powershell Command Line

In order to run a powershell script as a task sequence/application in SCCM or MDT, you will need to use the following command line in MDT/SCCM to correctly execute the script:


  • powershell.exe -executionpolicy bypass -File install.ps1
NOTE: You may need to enter the path to the powershell.exe and to the install.ps1, although for the install.ps1, it should see it from the path you enter in the working directory field. 

22 March 2013

Powershell: Public Desktop Environmental Variable

Powershell 3.0 now has a public desktop environmental variable, CommonDesktopDirectory, unlike versions 1 & 2. In order to make the powershell public desktop environmental variable compatible across different versions, use the following line:


  • $desktop = ([Environment]::GetEnvironmentVariable("Public"))+"\Desktop"

21 March 2013

Windows 8: Opening multiple application instances

In Windows 8, you can only open 1 instance of an app at a time by just clicking on the app tile. In order to open multiple instances of it, right-click on the app tile and run it as administrator. This will allow you to have several instances of the same application.

20 March 2013

Powershell: Adding powershell Run-as Administrator Option

For some Powershell scripts, they need the elevated privileges, even when UAC is disabled. In order to do this, there are two options.
  1. Run a cmd.exe session as administrator and execute the PS1 file from the command line.
  2. Add the registry key listed below to be able to right-click on a PS1 file and run-as administrator.
All you need to do is copy the info below to a blank notepad screen and then save it as {Filename}.reg. Double-click on the reg file and the key will be added to the registry, thereby adding the run-as administrator option. Here is the reg key to add the run-as administrator option:

You can download the reg key from here.

 Windows Registry Editor Version 5.00  

 [HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell\runas\command]  
 @="\"c:\\windows\\system32\\windowspowershell\\v1.0\\powershell.exe\" -noexit \"%1\""  

14 March 2013

Stopping system from locking

Most companies have a security policy enabled that locks a computer after a certain time interval to stop other users from being able to access the computer if the user forgets to lock the system when they step away. There are those times though that you need to prevent the system from locking for such things as a teleconference and you need to step away to the restroom. You will be booted from the teleconference if you lock your machine. Sometimes you may have a third-party vendor that, due to security reasons, has to remote in through your terminal in order to access servers for maintenance.

I wrote this program that will move the mouse cursor 6 places on the screen every two minutes and then clicks the control key. The executable is a wrapper that extracts the two Powershell scripts. The first script calls the script that actually moves the cursor, while the first script displays an OK button on the screen to click when you are finished. The executable wrapper then cleans up the Powershell scripts after OK is clicked. The executable was compiled using the old SMS installer.

Here are the three files. The executable contains the two Powershell scripts. It extracts them to the current directory and then executes them.

12 March 2013

Powershell: Robocopy Invalid Parameter Error

It is nice having robocopy integrated with PowerShell, but there are some quirks that can make it a pain to deal with. While I was writing a Powershell script that will automate the robocopy, I began getting the Invalid Parameter error. I went through troubleshooting it and made sure it was exactly the same I was typing in at the command line. I still could not figure it out until I split it up.

 $Source = "..\na_clients"  
 $Dest = "..\"+$Location  
 $Files = "*.*"  
 $Switches = "/R:0 /W:0 /E /MIR /TEE /Z /TIMFIX"
 $Logs = "/LOG:..\0ReplicationLogs\"+$Location+".log"  
 $ExcludeDIR = "0Archive","0ReplicationLogs","DfsrPrivate","DesignPremium32Bit","Indesign32bit"  
 RoboCopy $Source $Dest $Files $Switches /XD $ExcludeDIR[0] $ExcludeDIR[1] $ExcludeDIR[2] $ExcludeDIR[3] $ExcludeDIR[4]  

This is where I split up the robocopy command line into variables for each of the switches. That fixed the issue. Apparently, Powershell does not allow for you to be able to use spaces between the switches within a quoted variable. I went as far as dividing up the $Switches variable with a +[char]32+ between each quoted switch and it did no good. This below is the only solution I came up with.

 $Source = "..\na_clients"  
 $Dest = "..\"+$Location  
 $Files = "*.*"  
 $Retries = "/R:0"  
 $Wait = "/W:0"  
 $Logs = "/LOG:..\0ReplicationLogs\"+$Location+".log"  
 $CopySubfolders = "/E"  
 $Mirror = "/MIR"  
 $ConsoleWin = "/TEE"  
 $RestartMode = "/Z"  
 $FixTimeStamp = "/TIMFIX"  
 $ExcludeDIR = "0Archive","0ReplicationLogs","DfsrPrivate","DesignPremium32Bit","Indesign32bit"  
 RoboCopy $Source $Dest $Files $IPG $Retries $Wait $Logs $CopySubfolders $Mirror $ConsoleWin $RestartMode $FixTimeStamp /XD $ExcludeDIR[0] $ExcludeDIR[1] $ExcludeDIR[2] $ExcludeDIR[3] $ExcludeDIR[4]  


07 March 2013

WARNING - unable to set working directory: (-2147024894)

This error is caused when the working directory no longer exists that is assigned to the application being installed. It would be nice if MDT published which app it is, but it does not. To find the application, open up the BDD.LOG file. Search for the error message. You will see the directory it is trying to access on the line above. Just a few lines above, it should also display the app the directory is associated with right above the ################ line .

MDT: Unable to locate the Results.xml file needed to determine the deployment results

This error can be caused by several different things. Here are a few suggestions to look for:


  1. Have you inserted a new task before the boot image is installed? If so, this can trigger the error. (This was my problem. I was testing a new task to move the computer in AD in the Preinstall phase. When I disabled the task, the task sequence proceeded with no issues)
  2. Regenerate all new WIM boot image files
  3. Create a new task sequence and see if it proceeds normally. If it does, then just copy your custom tasks from the corrupted sequence to the newly created one
  4. Has this occurred since upgrading the MDT? If so, do step 3.
If you have encountered this issue and know of some other cause or fix, please post it here and I will update the blog. Thanks