Showing posts with label SCCM. Show all posts
Showing posts with label SCCM. Show all posts

Thursday, July 24, 2014

SCCM: "An error occurred while retrieving policy for this computer (0x80072EE7)" in WinPE

The Error:
Error 0x80004005 right at the beginning of the process.

The smsts.log shows 

Other Symptoms:
Client gets a DNS IP like fec0:0:0:fff::1%1

Solution:
Check and if required set the DHCP option 6 to define the DNS server address.

Wednesday, December 11, 2013

HOWTO Enable 8dot3 names when deploying Windows 7 with WinPE 4

8dot3 names are becoming less and less useful and is no longer enabled by default by Microsoft.

Here is one of the reason given in this article:
"The creation of 8.3 filenames and directories for all long filenames and directories on NTFS partitions may decrease directory enumeration performance. An 8.3-compliant file name refers to MS-DOS file-naming conventions. These conventions restrict file names to eight characters and restrict optional extensions to three characters."

A while ago we had an issue that 8dot3 names were no longer there. It turned out that the cause of the issue was that we had  mounted, edited and committed our WIM on a 2008R2 server where 8dot3 naming was disabled by default.
This caused some issues with some scripts relying on 8dot3 naming being present.

To check if 8dot3 names are present or not on a machine simply run
DIR /X C:\


It is important to check the root of the system drive because since the program files folder is always copied from the WIM to the disk this indicate whether the 8dot3 names are included in the WIM or not. Depending on how the following registry value is set you could have 8dot3 names created for new folder but missing for existing folders. All the details can be found in this TechNet article.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

Now, starting with WinPE 4.0 even if you have captured a WIM with 8dot3 names enabled, after you apply your image with an MDT or SCCM task sequence that uses WinPE 4, in other words relying on ADK 8, 8dot3 names are disabled again when the disk is formatted.

To work around this problem you can add a Run Command step in your task sequence with the command:
cmd /c format %OSDISK% /fs:ntfs /q /v:SYSTEM /s:enable /y


Here is a link to the technet forum post were this solution is detailed. All credits goes to them.


Tuesday, December 10, 2013

PowerShell one liner to format VARIABLE.DAT content

When investigating deployment issues with MDT all the variables used during deployment are listed under MININT\SMSOSD\OSDLOGS\Variable.dat

The file itself is not really easy to read and as it comes all in 1 line not easy to compare either.

Here is a one line power shell command that creates a text file out of an exported Variable.DAT

[xml]$xml = get-content "C:\temp\VARIABLES.DAT"; $xml.MediaVarList.Var | format-table -wrap | Out-File C:\temp\Variable.dat.txt

Here is a screenshot with the output of the result at the top and the unformatted file at the bottom.



Wednesday, November 20, 2013

PS Scripts to change File Association on your Windows 8 / 8.1 Image

Hello there,

A colleague of mine asked me if we could automate modifying file association when building images.

Here is the solution we came up with:

After a bit of google-fu-ing, it seems that there are two ways to accomplish this either through some HKCU   registry keys but some key permissions need to be changed or using DISM.

Here we are going to look at the DISM way.

Note that when using DISM the changes are not available for the currently logged in user but it works for new users. Therefore, this is a valid method when creating a custom Windows 8 / 8.1 image.

First we Need to export the current File association with DISM. To do this we will create a script called
Get-AppAssociation.ps1 with the following content:


param(

[parameter(Mandatory = $True )][string]$AssocXMLExportPath
)
DISM /online /Export-DefaultAppAssociations:$AssocXMLExportPath


Next we will create a second script called Set-AppAssociation.ps1 to check if the file extension to modify exists and if so modify it else add it to the xml file. This script also creates a backup of the original xml file.


param(
[parameter(Mandatory = $True )][string]$AssocXMLPath,
    [parameter(Mandatory = $True )][string]$Extention,
    [parameter(Mandatory = $True )][string]$ProgID,
    [parameter(Mandatory = $True )][string]$AppName
)

If(! (Test-Path -Path $AssocXMLPath".bak")){
    Copy-Item $AssocXMLPath $AssocXMLPath".bak"
}

[xml]$AssocXML = Get-Content $AssocXMLPath -Encoding UTF8
$Associations = @($AssocXML.DefaultAssociations.Association)
$Found = $False

foreach ($Association in $Associations){
    #Checks if the file association already exists and if it does update it. 
   If($Association.Identifier -eq  $Extention){
        $Association.ProgId = $ProgID
        $Association.ApplicationName = $AppName
        $Found = $True
   }
}

#If not existing association are found a new one is created and added to the xml
 if(!($found)){
        #Create a new XML element       
        $NewAssociationNode = $AssocXML.CreateElement("Association")
       
        #Set the attributes for the new element
        $NewAssociationNode.SetAttribute("Identifier",$Extention)
        $NewAssociationNode.SetAttribute("ProgId",$ProgID)
        $NewAssociationNode.SetAttribute("ApplicationName",$AppName)

        #Inject the new child to existing
        $AssocXML.LastChild.AppendChild($NewAssociationNode) > $null
}
$AssocXML.Save($AssocXMLPath)

Finally, we will use a third script to import those modified settings back to the image, using the script Restore-AppAssociation.ps1. Here is the content of the script.
param(
[parameter(Mandatory = $True )][string]$AssocXMLImportPath
)
DISM /online /Import-DefaultAppAssociations:$AssocXMLImportPath

And to bring it all together and demonstrate how to properly use those scripts here is a batch file that calls the 3 scripts above with parameters to modify the file extensions (pre-sysprep & capture).

cd /d "%~dp0"
::powershell set-executionpolicy remotesigned

:: Export the file association XML to the file system with DISM
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Get-AppAssociation.ps1 -AssocXMLExportPath "C:\OSD\AppAssoc.xml""

::modify the association XML content
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".bmp"  -ProgID "PhotoViewer.FileAssoc.Bitmap" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".dib"  -ProgID "PhotoViewer.FileAssoc.Bitmap" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".jfif"  -ProgID "PhotoViewer.FileAssoc.JFIF" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".jpe"  -ProgID "PhotoViewer.FileAssoc.Jpeg" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".jpeg"  -ProgID "PhotoViewer.FileAssoc.Jpeg" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".jpg"  -ProgID "PhotoViewer.FileAssoc.Jpeg" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".jxr"  -ProgID "PhotoViewer.FileAssoc.Wdp" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".png"  -ProgID "PhotoViewer.FileAssoc.Png" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".tif"  -ProgID "PhotoViewer.FileAssoc.Tiff" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".tiff"  -ProgID "PhotoViewer.FileAssoc.Tiff" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".wdp"  -ProgID "PhotoViewer.FileAssoc.Wdp" -AppName 'Windows Photo Viewer'"
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Set-AppAssociation.ps1 -AssocXMLPath "C:\OSD\AppAssoc.xml" -Extention ".pdf"  -ProgID "AcroExch.Document.11" -AppName 'Adobe Reader'"

:: Import the file association XML to the file system with DISM
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& .\Restore-AppAssociation.ps1 -AssocXMLImportPath "C:\OSD\AppAssoc.xml""

Well that is it for today, I hope you enjoy this post !!

Thursday, September 19, 2013

Lets talk about what SOE and GPO's are...

The first comment I got on my blog was from Niall Brady on Twitter  - who runs windows-noob.com - suggesting to explain what SOE and GPO's are, and although its not as fun as documenting technical solutions, he does have a good point, lets start with the basics.

Lets first start with defining SOE. SOE stands for Standard Operating Environment and as it is very well explained on Wikipedia, this refers to "a standard implemantation of an Operating System and its associated Software".
Basically, in my own words, it is a concept in which a standard is established to ensure that a given class of devices (Desktop, Servers, Laptops, Mobiles, Virtual Desktops, ... ) get the same standardized configuration of their respective Operating System and basic components ( i.e.: Flash player, Adobe Reader, Email client, Web Browsers, Office, ... ). Depending on the thickness of the SOE many or fewer basic components are included in the SOE image.

Now, lets talk a bit about GPO's, GPO stands for Group Policy Objects and those are used to configure and enforce given settings (aka. policies) in the Operating Systems and applications.
Policies can be enforced locally for devices that are in Workgroup in which case Local GPOs are used; or centrally for devices that belong to a domain in which case we simply refer to them as GPOs.
By enforced we understand that a user is not able to modify the setting put in place by the GPO and even when using work arounds - like modifying the registry - those settings are re-applied on the next GPO refresh cycle or when the device is restarted.

With Windows Vista/Server 2008 Microsoft also introduced Group Policy Preferences which gives the flexibility to set prefered settings but give the users the option to change those to their liking.

By using SOEs and GPOs in a domain environment devices can be administered centrally, The user experience and company policies can be set and globalized.
In a Workgroup environment they can be used to harden the security of  a pool of computers or simply set a standard however those devices cannot not be centrally managed.

Microsoft has also developped a number of tools that helps implement the concept of SOE's on large scales such as MDT (MS Deployment Toolkit) to capture and deploy Standard Images of a given Operating System; SCCM and the whole System Center suite which includes the same functionalities as MDT with many added features such as Software and Patch deployment and administration, reporting, ... Other vendors are also providing platform administration solutions BMC, Altiris, Landesk, ...

Well, that's it for today, I hope you enjoy the article and I look forwards to getting some comments !