New Blog Page

I will not use longer this blog page.

You can find my new blogs on: http://scug.be/blogs/nico

Nico

Be carefull with IPv6

I encountered the following with a customer, software was MDT 2010 update 1 used for LTI deployments.




At the end of the capture sequence the "Apply Windows PE" task was failing.

The log files didn't not tell much more then the screenshot. After some investigation I noticed my deploymentshare was responding with an IPv6 address.

The reason was that the traffic was going via the ISATAP router because the customer had Direct Access and UAG running.

To workaround this I disabled the IPv6 protocol during the capture process on the NIC

Remote Control Global Settings

With SCCM you can specify Remote Control Settings, unfortunately these settings are site settings so all the machines within your sites will have the same remote control settings.
So for instance, the setting that you prefer a pop-up that a user needs to allow you before you can remote control his machine...
Well this settings caused a challenge for me, as I got a group of critical kiosk machines that I want to take over remotely but I don't want that users have to allow me first.

From what I have heard within vNext we will be able to set Remote Control settings on each collection, this is awsome but for the moment with SCCM we need to workaround this.
How?

First scenario is to override the ‘Ask for permission when an administrator tries to access the client’ setting part of the Remote Tools Client Agent.
The following code is what the ConfigMgr client receives from the Management Point (T01 is the sitecode in this example):
instance of CCM_RemoteToolsConfig
{
PolicyID = "{GUID value}";
PolicyVersion = "x";
PolicySource = "SMS:T01";
PolicyRuleID = "{GUID Value}";
PolicyInstanceID = "{GUID value}";
Enabled = TRUE;
ComponentName = "SmsRemoteTools";
Type = 1;
RemoteToolsEnabled = TRUE;
AllowChat = TRUE;
AllowClientChange = FALSE;
AllowFileTransfer = TRUE;
AllowReboot = TRUE;
AllowRemoteExecute = TRUE;
AllowTakeover = TRUE;
AllowViewConfiguration = TRUE;
AlwaysVisible = FALSE;
AudibleSignal = TRUE;
CompressionType = 2;
ControlLevel = 2;
DefaultProtocol = "TCP/IP";
IndicatorType = 0;
PermissionRequired = 1;
UseIDIS = TRUE;
VisibleSignal = TRUE;
DisableToolsOnXP = TRUE;
ManageRA = TRUE;
EnableRA = TRUE;
AllowRAUnsolicitedView = TRUE;
AllowRAUnsolicitedControl = TRUE;
ManageTS = FALSE;
EnableTS = FALSE;
EnforceRAandTSSettings = TRUE;
PermittedViewers = NULL;
};
Note the PermissionRequired settings is set to 1 which states that permissions are required when running Remote Tools.
This is the value we have to overwrite by creating a new mof file.
The mof file will look like this:

#pragma namespace("\\\\.\\root\\ccm\\policy\\machine\\requestedconfig")
[CCM_Policy_PartialPolicy(true)]
instance of CCM_RemoteToolsConfig
{
// Header properties
PolicyID = "1";
PolicySource = "local";
PolicyVersion = "1";
PolicyRuleID = "1";
PolicyInstanceID = "1";
Type = 1;
// Data properties
[CCM_Policy_Override(TRUE)]
PermissionRequired = 0;
};

Watch the "PermissionRequired=0"

We save this file as for instance CustomRemoteControl.mof.

On each machine you want that the default settings gets overwritten with the new one you need need to compile this new mof file.

You can do this with:
%windir%\system32\wbem\mofcomp.exe CustomRemoteControl.mof

Upgrade to SCCM R3 (beta) - Issue with KB977384

I'm running SP2 R2 without issues and my version of the site server in the SCCM console is 4.00.6487.2000.



When trying to install the hotfix that is a prereq for R3, I got the error that my version of ConfigMgr is not valid..??



"The hotfix is not valid for this version of Configuration Manager 2007"



If I enable logging on the KB I get this version. - '4.00.6487.2700' This is indeed the version with ICP2 installed.



So more probably the International Client Packs is causing this. Installing the hotfix on a server without ICP works fine.

This is quite an issue as ICP's cannot be uninstalled.

I reported this to MSFT to make the version check a little bit more flexible.

Installing SCCM on Server 2008 machines

With IIS 7.0 (Server 2008) and IIS 7.5 (Server 2008 R2) there are some extra modifications you have to do to get SCCM up and running.
These are the ones I have encountered through the projects I did.

Install and enable webdav:
http://learn.iis.net/page.aspx/350/installing-and-configuring-webdav-on-iis-70/

RDC missing on Windows 2008:
http://www.windows-noob.com/forums/lofiversion/index.php/t487.html

Unable to install MP Control Manager and MP:
Check MPsetup.log, probably some webdav settings are wrongly set (true\false) and
an Authoring Rule was not created.
Allow property queries within infinite depth should be true
Allow custom properties should be false
Allow anonymous property queries should be true
Create Rule – Allow All users read to acc to all content

Install ASP to get Reporting to work.

With SQL 2005 on Server 2008:
------------------------------

http://support.microsoft.com/kb/920201
http://www.microsoft.com/downloads/details.aspx?FamilyId=FB0EE17E-96EB-4CBB-AC09-95A4DCF73077&displaylang=en

With SQL 2008 on Server 2008 no issues encountered (yet). :-)

SCCM Computer Association - keep same hostname

In a Replace Scenario, so when migrating from one machine to another one, you need to associate machines with each other in SCCM. This to make sure User Data gets restored correctly (State Migration Point). Some customers have choosen to keep the same hostname mostly because of machine names are linked to AD Security Groups.

This is an issue in the Computer Association wizard. As the wizard is expecting 2 different hostnames.



To workaround this you can enter a Dummy hostname for the new Machinne.



Now we can continue with wizard to associate machines with each other and to add the new machine to a collection where a Task Sequence is advertised.

Imagine we start to install the machine at this point, the hostname of the machine will be "SCCMDummy". So we have to do something extra.
We need to put a variable on the SCCM machine record that will make sure that OSDComputerName (SCCMDummy) will be overruled with the value that we want.
If you work with an MDT database you can put the value in the database of course.



To completely automate this you can find excellent example scripts in the SDK.

Migrate Windows 2000 machines to Windows 7

You shouldn't expect it but a lot of companies still have Windows 2000 machines running and some will ask to migrate. Migrating these machines with USMT (refresh or replace scenario) is not supported by Microsoft nevertheless it works. The supported way is to upgrade first to XP and then to Windows 7. You can already imagine how your customer will react if you will propose this migration track :-)

So, it works but there are some caveats though:

- USMT 4 will not run in a Windows 2000 shell, you can workaround this by running your scanstate command in Windows PE Shell. Short, you need to create a TS that will advertise your refresh scenario which will prestage Windows PE\Machine will reboot\Start up in Windows PE\Run scanstate\format disk\apply WIM\...

- Format Disk?? Yes. Hardlink doesn't seems to work. At least hardlink works but with this you need to wipe the disk as the MININT folder has the data on board. Well, wiping the disk was not really a success. When wiping the disk the installation of Windows 7 always failed. During the first reboot in Windows 7, the installation stopped with a fatal error probably because of NTFS issues..
When formatting the disk the installation of Windows 7 was a succes.

- SMP cannot be used as the task "Request State Store" does not work in Windows PE. So the variable %StateStorePath% needs to be specified in your USMT command.