You are browsing the archive for 2011 January.

FEP 2010 with ConfigMgr Integration : Computers are no longer accessible remotely

1:25 pm in ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, ConfigMgr SP2, configmgr2007, ConfigMgr2007 R3, FE, FEP, FEP2010, Installation, R3, SCCM 2007, SCCM 2007 R2, SCCM 2007 R3, SCCM 2007 SP2 by Kenny Buntinx [MVP]

Hi ,

When migrating slowly at a customer from Symantec Endpoint protection to FEP 2010 we encountered the following issue :

After the FEP client has been installed, the computer is no longer remotely accessible , even with RC.exe from System Center Configuration Manager

Problem Description : In some cases, after the FEP client has been installed, the computer is no longer remotely accessible using any form of remote control utility or Computer Management tools, including but not limited to Windows Computer Management, ConfigMgr Remote Control utility, DameWare, VNC. The cause has been found to be the Windows Firewall/ICS service that cannot be started. When an attempt is made to start the service, the resulting error is: Error 0x80004015: The class is configured to run as a security id different from the caller.

Possible solutions ( I say possible because it was linked to our environment) :

  • This appears to be the same error as reported in MS Support Article ID 892199, applicable to Windows XP SP2. The FEP client however is only installed on XP SP3 machines. When we used method 1 of the support article applied on the conflicting machine, the issue is resolved and is remotely accessible again. However we where not convinced and digged some deeper into it



The Authentic Users group only gets read permissions, not start/stop permissions as I feared, so I’m fine with that. I just left out the Power Users group as it’s not used in our environment.

It is imperative that you test this on one or two systems before rolling it out, and make sure it works well in your environment. I used this KB to identify Local Service and Network Service:


    Hope it Helps ,

    Kenny Buntinx

Configmgr 2007 OSD : Using Lenovo Update Retriever to install all your drivers without importing them in the ConfigMgr driver catalog

11:00 pm in ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, ConfigMgr SP2, configmgr2007, ConfigMgr2007 R3, Deployment, Drivers, Installation, Operating System Deployment, OSD, sccm, SCCM 2007, SCCM 2007 R2, SCCM 2007 R3, SCCM 2007 SP2, sccm2007, script, Task Sequence, Windows 7 by Kenny Buntinx [MVP]

Did you also think that driver management  in OSD could be more simplified ? For example when you have Lenovo devices , you need to also install a lot of “bad” drivers en also in a very specific way or features such as “hotkeys”does not work .Let’s look at the process right now:

1. Search drivers from the internet manually

2. Unpack them in a correct folder structure

3. Import drivers and categorize

4. Handle duplicate drivers

Problems often seen :

1. Not all drivers work with the import ( there are drivers that simply do not work with the export method , they need to run thru setup.exe ) HP is a king in that area with the sound card & Quick launch buttons. This means that the admin need to create packages , programs and multiple steps in the TS to let it work.

2. For getting some drivers you need to install the vendor msi on your test laptop , go to the install folder and find the extracted drivers there.After that you could import.

3. HP & Lenovo needs certain additional software such as HP quick launch , HP power manager , Lenovo Hotkeys , Lenovo think vantage , etc . A lot of those packages needs to be installed in a very specific order or it just don’t work .

4. You test your deployment and damn it seems you forgot 2 drivers . Find out by HWguid , download and import again …


Lenovo Update Retriever – Thinstaller solution :

If you don’t want to spent hours on searching, downloading and importing drivers for you LENOVO computer when going to build a Win7 image , read on . I have found a better way to accomplish this with thanks to Karel Serroels.

It normally takes so much time for an admin , while with the HP / IBM solution it is a 5 minutes job per HW model :


1. Install and run the Lenovo update retriever, select your model and software /drivers you want to install , download the drivers into a pre-defined file share . Nice , quick and easy .

2. Create a package with the Lenovo Thinstaller source files , copy the Lenovo Thinstaller files to the local disk & run it thru your TS


The advantage here is that I as an admin does not need to worry about the right install sequence , prerequisites , number of needed drivers or even OS type .The Thinstaller tool will do it for you .

Prerequisites :

Get the following software’s online from the Lenovo site as you will need it

  1. Link thininstaller:
  2. Link update retriever:


Step 1 : Install Lenovo Update Retriever on your server and follow instructions to create a share for the repository , etc .


Step 2 : Launch the Lenovo Update Retriever and select your Model an Operating System. Download all files to the repository.


Step 3 : Modify your Task Sequence and add Run Thinstaller Trustzone. It needs to work with 2.0 .

If you run Lenovo Thinstaller via Configuration Manager task sequence , you cannot run the installation program, because it is a .NET executable and the default policy is to disallow running it from a network share or distribution point. You must therefore change the  following ipadress and sharename with the one from your environment!


Step 4 : Create the Lenovo thinstaller package in Configuration Manager.


Step 5 : Copy the Lenovo Thinstaller directory to C:\Windows\Thinstaller


Step 6 : Run Thinstalle with the following commend line . You must therefore change the  following ipadress and sharename with the one from your environment!


Step 7 : Remove the Thinstaller source files . Do a nice cleanup .



There you go .. The only disadvantage from using this , is the fact that your sourcefiles need to be always to one spot . You can solve this by using Sysvol , DFS or other technologies . However , Most companies have a team that will build the initial image on site and than replicate the images across the company .

Hope it helps ,

Kenny Buntinx.

Configmgr 2007 : PXE boot & MTFTP……. defaulting and make you wait for 10–15 minutes

6:23 pm in Uncategorized by Kenny Buntinx [MVP]

Problem :

I am trying to setup OSD at a customers site. I am having issues when trying to network boot a client.  When doing a Network boot the client picks up DHCP information correctly and then displays "MTFTP….." and the dots continue on for quite some time(about 15 min), switch over to normal TFTP and then the PC will boot into Windows PE Running the task sequence as expected.

Within Site Management->Site->Site Settings->Site Systems->ConfigMgr Distribution Point I have the box for multicast unchecked.
Within Site Management->Computer Management->OSD deployment->Operating System Images-> under my target image’s distribution settings I have "allow this package to be transferred via multicast" unchecked.

So I didn’t know where that MTFTP came from and I didn’t know why my client is defaulting to a MTFTP connection instead of a normal TFTP connection? 

Solution :

On your DHCP scope , disable or delete any option 43 as shown below in the picture and asign them to specific reservations :



Explanation :

The customer has a cisco wireless AP in place with a cisco wireless LAN controller . In the DHCP scope options the option 43 called “Vendor specific option” is set.

When Cisco’s Wirelesss Unified Architecture is deployed, the Lightweight Cisco Aironet Access Points (AP) can use a vendor specific Dynamic Host Control Protocol (DHCP) Option 43 to join specific Wireless LAN Controllers (WLCs) when the WLC is in a different subnet than the LAP. 

If I looked closer , I saw that is was a ASCII value that option 43 was representing was an IP address.

Option 60 is included in the initial DHCP discover message that a DHCP client broadcasts in search of an IP address. Option 60 is used by the DHCP Clients (LAPs in this case) in order to identify itself to the DHCP server.

In order to facilitate AP discovery of WLAN controllers that use DHCP Option 43, the DHCP server must be programmed in order to return one or more WLAN controller management interface IP addresses based on the VCI of the AP. In order to do this, the DHCP server is programmed in order to recognize the VCI for each access point type, and then define the vendor specific information.

On the DHCP server, the vendor specific information is mapped to VCI text strings. When the DHCP server sees a recognizable VCI in a DHCP discover from a DHCP client, it returns the mapped vendor specific information in its DHCP offer to the client as DHCP Option 43. On the DHCP server , option 43 is defined in each DHCP pool (Scope) that offers IP address to the LAPs . In my case the AP’s  were on the same scope as my PXE clients , and those AP’s connect to the WLC with option 43 that is using MTFTP for Access points.. Unfortunately the Bootrom of the network card doing PXE is programmed to let option 43 go first , pointing with that IP address to the Mtftp service running  on the WLC (which is in this case referring to the WLC )


Hope it Helps ,


Kenny Buntinx