SCAPaoT

Did you ever saw a error 19 in a tasksequence for rolling out office 2010 or other apps with SCCM 2007 R3?

The error 19 is pointing towards “drive is read only” and the smsts.log looks that way:

In our case, the issue was pointing towards the office 2010 installation files, because it is installed using an cusomtized msp created with /admin argument.
And in there where several things in the msp pointing towards this direction like custom template stores and so on.

But Office wasn’t the culprit. All was caused by bitlocker.
Yes, bitlocker.

If you ask why bitlocker, here is the answer:
The files for the installation of office 2010 where cached for local deployment and support of roaming users.
The bitlocker GPO in the active directory domain was set to:
Deny write access to fixed drives not protected by BitLocker

As the tasksquence tries to store the data on the drive with the highest avaiable free space, the second partition was used.
But as the partition wasn’t encrypted yet, the creation of the _SMSTaskSequence folder failed with “drive is read only” error 19.

We have decided to submit a but report on this error as we couldn’t understand why the cache tries to place the files on a read only drive.

So, if anyone else stumbles on that, check you GPOs and as a best practise, apply the GPO after installation hast finished…

Hello,

as written in the post “Change Bitlocker PIN without administrative rights using SCCM” we builed a little gui for non administrative users to change the bitlocker pin.

We where really astounded about the feedback and the questions on how to get the tool or the source code. So we decided to bring it up on Codeplex.

And here it is: http://blpintool.codeplex.com/

Project Description
Deploying Bitlocker with Windows 7 in enterprise environments works pretty nice with the new features which have beend implemented by microsoft. There’s still one big problem to solve. Users can’t change their PBA Bitlocker PIN without administrative priviledges.

Feel free to give away this link and grab the tool on codeplex.

We had to install the SQL 2005 Reporting Services (included with the SCCM – License of our customer) for enabling the reporting point on the SCCM Site server. The operating system is Server 2008 x64.
But as we started the SQL Server installer, the nothing of the installation features where shown except from the client tools and documentation.
All requirements where checked sucessfully, but installing Reporting Services wasn’t shown.

So we tried a lot of things, enabled 32 bit apps in IIS, restarted several times, added IIS features and so on.
But everything we didn’t show up the selection of Reporting Services feature.

So we started looking at the other software that was installed on that server and found the “Reporting Services 2008 Viewer Redistributable SP1″ installed.
And what to say: that one is the cluprit.
It was installed with the WSUS-Feature.
Removing it shows up the complete feature list in the SQL  Server Installer.
But the WSUS started to throw bad messages until we installed the viewer again.

Microsoft announced the beta 1 of SCCM v.Next on yesterday.

With SCCM v.Next Microsoft buildes the next version of it’s systems managment and software distibution platform formaly also known as SMS.

To get more informations, read the original post here: http://blogs.technet.com/b/systemcenter/archive/2010/05/24/the-next-generation-of-client-management.aspx

A few weeks ago,
(http://www.scapaot.de/blog/?p=57),
I have written about the question if there will be Powershell support in SCCM vNext.

On yesterday I had the chance to listen to a very interesting talk from Microsoft about the user centric software deployment and SCCM vNext.
There I had the chance to ask about the Powershell support in the next version.

The answer is:

The next version has support for the same WMI classes
as it has in SCCM 07.
And there will be new WMI classes for the new features.
Powershell support is there using WMI cmdlets.

And perhaps the SDK for vNext will have some little more infos about using the Powershell to manage SCCM.
Cmdlets are not planed at the moment.

So, for all of you want to learn how to automate SCCM,
go out and learn something about WMI.

Most of you already know the power of Powershell. Also more and more products, also of the System Center family, have support for Powershell.

But what about SCCM?

In the actual version, SCCM 2007, there is little support for Powershell.
Only because the Powershell has a small amount of cmdlets for WMI, it can be used for managing, administration and automation on SCCM.

So what’s about Powershell support in SCCM vNext?

As I’m very interested in that topic I have asked several people including MVP’s and the technical partner line from Microsoft to get a hint.
All answers are pointing towards the same direction:

“No official statement at the moment, please look forward to MMS 2010”

So, in the words of Douglas Adams: “DON’T PANIC”,
just be patient for a few days more…

While everyone is talking about Bitlocker, there are still some tasks to be done if your going to deploy it in an enterprise.
One of these tasks is, that non administrative users are not allowed to change the Bitlocker PIN (if you decide to use TPM and PIN as protector for the system drive).

At our own environment we decided to use the SCCM to accomplish this task.

1. We built a nice little app (VB.net) that uses the Bitlocker WMI interface to get the new PIN from the user.
2. We built a little program that executes an advertisement using the command line. This is done using the UIResource.UIResourceMgr-Class.
3. We made an package in SCCM with a program called “Set-Pin”. This package has “Persist content in client cache” enabled so execution works also in notebooks without access to the SCCM. Also it was set to execute “Only when a user is logged on” and “Run with administrative rights” and “Allow users to interact with this program”.
   This package is advertised to each client without an mandatory assignment, so it can be executed by each client as often it is started.

Now every client has a link in the start menu that executes the SCCM package (PackageID) and the program “SetPin” with administrative rights (as the SCCM-agent has administrative rights on the client).

As a nice little addition, our little tool was built with a “force” method. So we can force people to set the PIN (for example, on every new system or when a system changes his owner).

I have to say a big thanks to “the god of programming” for his support on building the little apps!

Servers mostly run with fixed IP-Addresses. So a question was to automate the server deployment using SCCM that also adds a fixed IP-Address to the server.

While SCCM has the ability to add a fixed IP-Address, the thing to do the deployment automatically was to add the OSD-Variables to the computer object in SCCM.

This can be done using a simple Powershell script and the WMI-Classes brought with SCCM.

# Powershell V2 only (V1 has errors in WMI)
param([string]$computer = ".",[string]$smssite = "MND",[int]$ResourceID=-9999,[string]$variable,[string]$value)

if(($ResourceID -ne -9999) -and ($variable -ne "") -and ($value -ne ""))
{
$pc_class = [WmiClass]""
$pc_class.psbase.Path ="\\$computer\ROOT\SMS\SITE_$($smssite):SMS_MachineSettings"
$pc = $pc_class.createInstance()

$pc.ResourceID = $ResourceID
$pc.SourceSite = $smssite

$pc.psbase.get() 

$pc.MachineVariables = $pc.MachineVariables + [WmiClass]"\\$computer\ROOT\SMS\SITE_$($smssite):SMS_MachineVariable"

$machinevariables = $pc.MachineVariables 

$machinevariables[($machinevariables.count)-1].Name = $variable
$machinevariables[($machinevariables.count)-1].value = $value

$pc.MachineVariables = $machinevariables 

$pc.put()

if($?)
{
  "Variable set"
}
else
{
  "Error in setting variable"
}
}
else
{
  "Not enough arguments given."
}

Adding variables this way is very easy and the correct names can be found in the SCCM documentation (http://technet.microsoft.com/en-us/library/dd252744.aspx).