## Saturday, 16 April 2011

### Unresponsive Flash player applications

If you are using flash based software which becomes unresponsive to clicks, this may be due to Flash player not trusting the file or path you are accessing. To work around this problem you may require a config file to allow flash to trust a file location. In order to open things up ensure you have a folder called 'FlashPlayerTrust' in the following path.

'C:\Windows\system32\Macromed\Flash\
'

Within this folder create a file with the .cfg extension, inside this file you will require the path of the folder you wish to trust, you can put multiple paths in this file, one on each line

e.g.

C:\Path\to\application\1
C:\Path\2
C:\Any\Other\Path

Just to make sure, give the machine a restart and you should find the application now works as expected.

## Friday, 8 April 2011

### Installing Sims via a script

If the need arises to install Sims onto a large quantity of workstations and Solus 3 is not an option you can use the following script, the only changes needed are to ensure that the connect.ini and sims.ini files are located in the root of S: and to edit the second line of the script to match your own situation.

@echo off
net use S: \\SIMSSERVER\SIMS-SHARE password /user:DOMAIN\Username

S:\SIMS\Setups\simsinfrastructuresetup.exe -a {QuietMode} {SIMSWorkstation} {FMSWorkstation}
S:\SIMS\Setups\simsapplicationSetup.exe /S {QuietMode} [SIMSDirectory="S:\SIMS" [SIMSDotNetDirectory]="C:\Program Files\SIMS\SIMS .net"
S:\SIMS\Setups\simsmanualSetup.exe /S {QuietMode} [SIMSDirectory]="S:\SIMS" [SIMSDotNetDirectory]="C:\Program Files\SIMS\SIMS .net"
S:\SIMS\Setups\simsamparkSetup.exe /S {QuietMode} [SIMSDirectory]="S:\SIMS" [SIMSDotNetDirectory]="C:\Program Files\SIMS\SIMS .net"
XCopy S:\connect.ini "C:\Program Files\SIMS\Sims .net" /y
XCopy S:\SIMS.ini "C:\Windows" /y
net use s: /d

## Thursday, 7 April 2011

### WMI Filters for different Windows versions

In order to run multiple operating systems in the same OU structure  and have relevant GPO's applied we can make use of WMI filters. These filters can be used to interrogate the operating system and either apply or not based on the result.

I will not go into how to create a WMI filter here as if you are here looking at this then you only really want the query needed to create the filter.

The basic filter will take the following format

Select * from Win32_OperatingSystem Where Version like “x” and ProductType = “y"

OS Version

The relevant  OS version values are as follows, these can be substituted in place of x:

Windows 7 or Server 2008 R2 = “6.1%”
Windows Vista or Server 2008 = “6.0%”
Windows XP = “5.2%”
Windows 2000 = “5.0%”

Product Type

To filter by roles the computer may perform, change the ProductType (y) to:

Client = “1”
Server running a Domain Controller role = “2”
Member server (server that’s not a DC) = “3”

## Tuesday, 5 April 2011

### Modifying Deploymentmonitor.hta

In a previous post I mentioned a utility from the Microsoft Deployment Guys which allows you to monitor how your Litetouch build is progressing. In this post I am going to show how you can modify the utility to make it a little more appropriate to your own needs.

The utility itself is a HTA file which can be edited in a text editor, my editor or preference is notepad++ as it supports several different languages and will indent and colour code languages it understands as necessary to make things easier to follow.

Onto the file itself:

Lets start early on at line 7

MINIMIZEBUTTON="NO"

for some reason the Deployment guys didn't feel the need to minimize the app to the taskbar, however in the world of education we are often doing at least three things at once and to keep the screen as uncluttered as possible you can edit the line to

MINIMIZEBUTTON="YES"

and instantly you have the option to put things out of the way.

If you are using this in a fixed location you may want to prepopulate the location for the script to check for log files, this can be done by editing line 278 from

<input id="lblEventShare" type="text" name="lblEventShare" />&nbsp;&nbsp;&nbsp;&nbsp;

to

<input id="lblEventShare" type="text" name="lblEventShare" value="\\servername\Share$" />&nbsp;&nbsp;&nbsp;&nbsp; To automatically check the autorefresh box when starting the app change line 292 from  toYou will still need to click the refresh button once to start the process.To change the frequency that the app automatically checks for updates edit line 203iTimerID = window.setInterval("Refresh", 120000)You will also want to edit line 292 to reflect the changed time you have set. Auto-refresh every 2 minutes (press 'Refresh Display' to start)every 2 minutes (press 'Refresh Display' to start)Hopefully these changes will make this great utility more useful in your deployment efforts. ### Import drivers into MDT maintaining folder structure I recently got an email from Johan Arwidmark's mailing list at Truesec, this mail contained a powershell script to import drivers into MDT whilst maintaining the folder structure, this will allow multiple driver imports for a range of hardware without dumping all of the drivers in on huge lump in the 'Out Of Box Drivers' folder. The Drivers folder layout will follow the format as follows Drivers\ |------OS 1\ | |--------->Manufacturer1\ | | |----------->Model1\ | | |----------->Model2\ | |--------->Manufacturer2\ | |----------->Model1\ | |----------->Model2\ |------OS 2\ |--------->Manufacturer1\ | |----------->Model1\ | |----------->Model2\ |--------->Manufacturer2\ |----------->Model1\ |----------->Model2\ You will need to edit the first three lines of this script to match your environment, otherwise it should be good to go.$DriverStore = "C:\Drivers"
$MDTDSRoot = "C:\MDTBuildLab"$PSDriveName = "DS001"

Add-PSSnapIn Microsoft.BDD.PSSnapIn
New-PSDrive -Name "$PSDriveName" -PSProvider MDTProvider -Root$MDTDSRoot
# Proces each of the operating systems folders
Get-ChildItem "$DriverStore" | foreach { # Display the folder we are processing Write-Host "Processing$($_.FullName)" -ForeGroundColor green;Write-Host "" # Create the operating system folder in the MDT 2010 Deployment Workbench new-item -path$PSDriveName":\Out-of-Box Drivers" -enable "True" -Name "$($_.Name)" -ItemType "folder" -Verbose

# Process each of the vendor folders
$OSFolder =$_
Get-ChildItem $_.FullName | foreach { # Display the folder we are processing Write-Host "Processing$($_.FullName)" -ForeGroundColor green;Write-Host "" # Create the vendor folder in the MDT 2010 Deployment Workbench new-item -path$PSDriveName":\Out-of-Box Drivers\$OSFolder" -enable "True" -Name "$($_.Name)" -ItemType "folder" -Verbose # Process each of the model folders$VendorFolder = $_ Get-ChildItem$_.FullName | foreach {

# Display the folder we are processing
Write-Host "";Write-Host "Processing $($_.FullName)" -ForeGroundColor green;Write-Host ""

# Create the model folder in the MDT 2010 Deployment Workbench
new-item -path $PSDriveName":\Out-of-Box Drivers\$OSFolder\$VendorFolder" -enable "True" -Name "$($_.Name)" -ItemType "folder" -Verbose # Import the drivers into MDT 2010 Deployment Workbench Import-MDTDriver -Path$PSDriveName":\Out-of-Box Drivers\$OSFolder\$VendorFolder\$($_.Name)" -SourcePath "$($_.FullName)" -Verbose
}
}
}

During testing of this script I encountered errors while creating folders, this error appears to be down to the code using  '-enable "True"' powershell spits this out with some ugly red lettering, I have found that by removing this part of the code the script appears to run perfectly and populate MDT as we hope.

## Friday, 1 April 2011

### Monitoring MDT Litetouch task sequence

When using MDT to deploy machines in school, we currently have the system set so that we enter a computer name and pick an image type then everything else is automatic, we have the machines put into the computers container in AD, this is due to the fact that we have not set MDT to automatically name and place machines yet.

If the need to rebuild a machine arises we will start off the process and leave the machine running, the task sequence will lock the workstation wherever necessary due to the system being logged on as an admin account, however the difficulty lies in knowing when the build has completed and being able to move the computer to its correct OU.

If we move the machine too soon then other scripts will run which may affect the task sequence such as the installation of antivirus which may quarantine needed files. If we fail to move the machine then it will be built and on the domain but will have no curriculum software,

MDT has a useful feature which can write log files as each stage of the task sequence is completed, using this you can monitor how far along a machine is.

To set this up:

1. Create a share on a server, you can use either an open or hidden share.
2. Edit the Default section in your deployment share customsettings.ini to include the following line.

EventShare=\\Servername_or_IP\Sharename\$

3. Update your deployment share.

Any new builds you start will write log files to the shared folder, initially the log will have a MININT name but as soon as the computer is given a correct name the logs will use this.

To make it easier to monitor what is going on in these logs the Deployment guys have written a utility to display the current info in an easier to read format, this can be downloaded from the original post.

Essentially the utility is a HTA which will monitor a given folder which you set, the optional refresh period of two minutes will allow you to keep a background eye on the build process.

To use the utility, download and extract the zip file from their page to a relevant location, double click on the DeploymentMonitor.hta file. Enter the path to the share you created and click refresh. The utility will return the contents of the folder, if you wish to have the utility update every two minutes tick the checkbox and then click refresh.

This utility will not clear out the folder so you will need to perform some housekeeping from time to time depending on how many builds you perform as the folder will gradually fill up with old info.

Disclaimer::
As with all of the Deployment/Scripting Guys utils they are provided with no warranties or guarantees of any kind, their use is entirely at your own risk.