Whilst at a customer recently I had a requirement to run a ‘Diskpart /Clean’ at the start of a task sequence to remove any encryption on the drive, in this case McAfee. I have done this several times in the past however always hit a few niggles so thought I would blog to refer to in the future

The easiest way to do this is to perform the following;

1. Mount your Windows PE image(s) to a directory
2. Create a text file called ‘CleanPartitions.txt’ (for arguments sake), with the following content;
   • Select Disk 0
   • Clean
3. Copy this text file to ‘<Mounted Folder>WindowsSystem32′ (again, for arguments sake)
4. Commit the mounted folder back to the .WIM

In your task sequence, before the standard ‘Format and Partition Disk’ phase, perform the following;

1. Add a ‘Run Command Line’ task
2. In the ‘Command Line:’ text area, type;
   • diskpart.exe /s “%windir%system32CleanPartitions.txt”
3. Disable 64-bit file redirection
4. Save the task sequence

This should now run successfully and remove any encryption on the drive

It is worth noting that this will only work in a Lite-touch situation as you will need to either PXE-boot or use bootable media. There is a solution that McAfee have released that allows you to perform this end-to-end in a Zero-Touch situation that I will blog about soon.

Cheers

SteveH

I came across the following error message recently whilst troubleshooting an SCCM Distribution Point;

————————————————————————————————————————–
There was an error while performing this operation.

Details:
Filename: \?C:inetpubwwwrootweb.config
Line number: <LineNumber>
Error:  Cannot add duplicate collection entry of type ‘<XXX>‘ with unique key attribute ‘<YYY>‘ set to ‘<ZZZ>‘.
————————————————————————————————————————–

Client’s were downloading packages via SMB rather than over HTTP which prompted me to check if WebDAV had been configured… upon clicking on the WebDAV feature configuration page the error appeared.

Turns out this was quite a simple fix – WebDAV had been configured at the Server Level, rather than at the Site level which a) resulted in this error and b) seemingly broke WebDAV and was the cause of the issue with the DP. Simply delete the configuration at the Server Level, and set your configuration at the site level.

Thanks
SteveH

Whilst recently implementing out of band management for a customer, I had an issue whereby the out of band console would not connect to any provisioned system. The connection status transitioned between; connecting, busy, disconnected and the oobconsole.log file stated;

GetAMTPowerState fail with result: 0x80072EE9

The power control options provided by OOB worked fine, – however these utilise TLS authentication as opposed to HTTPS for the console. Certificates are often the cause of much headache in OOB and after some searching came across a rep on the Intel vPro website suggesting that if the AMT web server certificate (issued to all AMT clients) was issued by a subordinate CA then to attempt adding this into the trusted root certificates for the local computer (that is running the OOB console)

Hallelujah! The console then connected fine

A customer recently wanted to create a security right in Configuration Manager that allowed a user to create packages; both physical and virtual whilst restricting access to the other components in the console.

At first glance this seems a fairly trivial task – create a group and add it as an user security right in SCCM, then assign the required classes – in this case;

• Collection – Read
• Package – Full

This had the desired effect for physical packages however the option to create a virtual application package was gone.

Several minutes of adding each class one at a time found that the ‘Site’ class with ‘Read’ and ‘Manage SQL Commands’ is required to display the option to create a virtual package. This complicates things a little as it allows users to make changes to certain attributes in the ‘Site Settings’ section – to mitigate this I added instance security rights to the primary site node giving the group I had created no permissions.

Cheers,

Ran into this issue when launching Outlook 2010 after a USMT migration.

Cannot open your default e-mail folders. The attempt to logon to Microsoft Exchange has failed.

The scenario is a  Windows XP SP3 with Office 2003, to Windows 7 SP1 with Office 2010 RTM migration.

User State Migration Toolkit (USMT) 4.0 was used to copy the profile, this included the USMT update to support Office 2010 which can be downloaded here http://support.microsoft.com/kb/2023591

The profile and user settings had migrated successfully, however it appeared that the Outlook profile didn’t migrate.

This is a known issue and an Outlook hotfix is available from Microsoft at the following location.

http://support.microsoft.com/kb/2405793

Once the hotfix is installed the profile opens fine, and all settings are migrated.

This hotfix can be added directly into the task sequence, or into the Office package.

To add into the Office package extract the fix into the updates folder using the following command.

outlook2010-kb2405793-fullfile-x86-glb.exe /extract:c:<extractiondirectory>

Then copy the two files into the updates folder of the Office 2010 installation sources files

Once you deploy Office 2010 from the updated media, the update will be slipstreamed into the install.

John Riseam

System Center Consultant

Risual Ltd

Here are 2 useful queries which will allow you to create separate x86 and x64 Windows 7 SCCM collections which will come in handy when your pushing out programs that are architecture specific.

Windows 7 x86

select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where (SMS_R_System.OperatingSystemNameandVersion like “%Workstation 6.1%” or SMS_R_System.OperatingSystemNameandVersion like “%Windows 7%”) and SMS_G_System_COMPUTER_SYSTEM.SystemType = “x86-based PC”

Windows 7 x64

select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where (SMS_R_System.OperatingSystemNameandVersion like “%Workstation 6.1%” or SMS_R_System.OperatingSystemNameandVersion like “%Windows 7%”) and SMS_G_System_COMPUTER_SYSTEM.SystemType = “x64-based PC”

We came across an issue today with a certain update being pushed out via SCCM “Security Update for Microsoft .NET Framework 4 (KB2416472). Basically the downloading of the file was stuck at 66%.

I then looked for this update in my update list in the SCCM console, i came across the update and went into the properties of it. On the content tab i noticed that all the update was not downloaded.

So i then went back to software updates and searched for the update in my update repository and then i re-downloaded the software update into my Updates deployment package.

I then went back into the properties of the update and could see on the content information tab that all 3 components were downloaded.

The next step was to update the Distribution Point so that it picked up the newly downloaded files. By going to distribution points under your update deployment package and choosing update distribution points and waiting for the source version of your package to update (Check via package status)

I then rebooted a client with the issue and then the update sprang into life

We stumbled across an issue recently where all of a sudden we couldn’t RDP from windows 2003/XP machines to Windows 2008/Vista machines. The first thing we dis was run a Resultant set of policy on a windows 2008 machine applying NLA and the setting was being applied by local policy.

An SCCM agent was installed recently on all machines in the environment , so our next port of call was to pursue this route. So we started to look through the SCCM console and stumbled across the setting which was causing the issue.

The Setting is configured in the below location in the SCCM console.

• Site Database > Site > Client Agents > Remote Tools Client Agent > Remote Desktop

As you can see above NLA is enabled, so if you uncheck this, you’ll see your issues fade away

I have a SCCM server installed on site to deal with client and server machine patching. After the last patch Tuesday I noticed that the windows updates under Software Updates had not been synchronized with the latest updates. To dig deeper into this I navigated under System Status – Site Status – <<site name>> -Component Status and noticed that the SMS_WSUS_SYNC_MANAGER component was in a warning state. By right clicking and selected Show Messages – All i was able to see a bit more information:

The entire description is as follows:

SMS WSUS Synchronization failed.

Message: Thread was being aborted.

Source: Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction.SyncUpdates.

Seems strange that the thread was being aborted so I decided to have a look at the good old Application event viewer to see what was going on at a similar time. I found that the SMS_SITE_BACKUP component was running a split second after the SMS_WSUS_SYNC_MANAGER component which was causing the SMS_SITE_VSS_WRITER component to stop the SMS services as part of preparing for backup (wow that’s a lot of components in one sentence!)

I then changed the schedule start after property for this back up component task by navigating to Site Management – <<Site Name>> – Site Settings – Site Maintenance – Tasks – Backup ConfigMgr Site Server Properties and set the Schedule to run at a time that doesn’t conflict with the synchronization (just an hour later than it was).

This solved the issue and updates are synchronizing happily again now

Hopefully this can save you some valuable troubleshooting time!