20 February 2012

"The file AdobePDF.dll is needed" when installing CS3 on Windows 7 64-Bit

Unlike what most blogs are saying that you need to extract the AdobePDF.dll from the data1.cab file, which is one option, there is a much easier and faster way of doing it. It is already extracted and available to use. When the window appears displaying the above error, do the following

1) Click Browse

2) Click the Folder Up icon

3) Double-Click AMD64 folder

4) Double-Click AdobePDF.dll

5) Click OK to continue the installation

That is all that is to it. The installation will now continue with no further stops. 

07 February 2012

The Basics of SMS/SCCM MIF files

First off, the firm I work for still uses SMS 2003. MIF files are used in both SMS and SCCM. It sucks that there is so little information about MIF files. A MIF is a data snippet file that is collected and read when the SMS/SCCM hardware inventory is run on a machine. The file contains unique data pertaining to the machine it was generated on, which is reported to SMS/SCCM. A MIF file is nothing more than a set of definitions that SMS/SCCM collects to present in the resource explorer.

MIF File Location
This MIF is placed in the %WINDIR%\SysWOW64\CCM\Inventory\noidmifs directory on a 64-bit operating system and %WINDIR%\system32\CCM\Inventory\noidmifs on a 32-bit operating system. The name of the MIF file is not important. Once you place the MIF file in the directory, the next time a hardware inventory is run on the machine, the file will be collected and removed from the directory.

Detailed Usage
A MIF has no programming dynamics in it. To successfully generate and report MIF files back to SMS/SCCM, there needs to be a script run on the machine that determines the data to report. There are two ways to generate a MIF. The first and easiest is to manually create a MIF for each possible outcome of the desired operation, thereby the script copies the pertinent MIF to the noidmifs directory for reporting. The reason you want to use the noidmif is because SMS/SCCM automatically associates the MIF with the client it was collected from if it is in this directory. IDMIF files are data files not associated with the client it was collected from. The second option is to create a MIF template. The script will perform the operation to determine the data to be reported to SMS/SCCM and then reads the contents of the MIF file to edit the attribute section, modifying the output being reported to SMS/SCCM.

Here is an example I created at the firm I work for. This MIF reports back to SMS/SCCM if the User Account Control is disabled on a machine. There can be multiple attributes reported under a single group and multiple groups reported under the component.
 Start Component  
     Name = "UAC Info"         Name of the MIF being reported  
     Start group                Group of subsections being reported to SMS/SCCM  
          Name = "UAC Info"     Name of the subsection in the Resource Explorer under Hardware  
          ID = 1               The sequential number associated with each subsection being reported  
          Class = "UACInfo"  
          Start Attribute  
               Name = "Status"    Name of the column in the subsection  
               ID = 1           Sequential number associated to each attribute being reported  
               Type = String(10)   Data type being reported  
               Value = "Disabled"  Actual data being reported  
          End Attribute  
     End group  
 End Component  

The above screenshot shows the output to SMS from the above listed MIF file

03 February 2012

MDT 2010 -- Failure (ERR):68: Ran diskpart to change drive letter - Device unavailable

This error, which occurs in both MDT 2010 and MDT 2012, is caused when the USB thumb drive is left in the USB port after the initial WinPE is loaded and the imaging process is initiated. Simply removing the USB thumb drive after WinPE loads corrects this error. Once the Task sequence wizard is loaded, everything has been loaded into memory from the USB, hence it can be removed. In the end, either ignore this error, or remove the thumb drive after WinPE loads.

This error is caused by the fact that the USB thumb drive is assigned the drive letter c: as the WinPE loads. During the initial Litetouch.wsf processes, it is checking to make sure c: is available for the drive letter where the OS will be laid down. If it is not available, the Litetouch.wsf will try and reassign a new drive letter to the thumb drive. It is at this point where the error occurs. It is an invalid error because when the system reboots, the drive letter is reassigned and c: is assigned to the primary HDD where the image is being laid down.