You are browsing the archive for 2009 June.

SCCM 2007 : PXE BOOT with VMWARE Workstation and Trend Micro AV not working !

9:08 am in ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2 by Kenny Buntinx [MVP]

PXE booting in your VM-Environment will not work unless you disable the Trend micro common firewall driver on your physical host . This is a known issue for Trend Micro !

To do this , follow the steps below.

Go to your control panel and select your network card .


Select your network adapter and select properties. The following screen appears.


Deselect the Trend Micro Common firewall driver and select “OK”.It is been disabled now.

PXE booting on VMWare Workstation Machine should work from know on ! Once your machine has been build you can turn it back on !


Hope it Helps ,


Kenny Buntinx

Community Day 2009 : Getting ready

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

Tomorrow I am delivering a session about “Thin , Thick or Hybrid Imaging – Notes from the field” at the Community day 2009.

After a hectic week , I finally got ready with my demo and my slide deck.

I had the luck of destroying my hard drive with all of my demo’s on Tuesday , just after finishing off my configuration. Guess what ! No backup …

Finally everything is falling into place , so relax , sit back and enjoy the show for tomorrow!


Hope it helps ,


SCCM : Backing up secondary sites isn’t supported !

5:10 pm in Uncategorized by Kenny Buntinx [MVP]

Recovery off a secondary site is not supported with SCCM , backing it up is !  Only a reinstall is supported for secondary site. This news I received yesterday from PSS support , after we ran into an issue with the VSS Backup writer at a customer.I did not know it wasn’t supported , as the functionality is there to configure it. Why don’t they block this possibility on secondary sites if recovery is not supported.

But , I do agree there is not much on a secondary site of value to back up. Since backup does not save packages, the only things lost in a failure that could be recovered would be transient client data that has not yet been sent to the primary site and some configuration details on the secondary. Since clients are assigned to the primary site we can use a replacement secondary right away. Worst case scenario would be to resync inventory on some of your clients depending on how much ‘in flight’ data lives on our secondary.

Just to let you know , hope it helps ,

Kenny Buntinx

SCCM : Recommendations for PKI Key Lengths and Validity Periods with Configuration Manager

5:51 pm in Uncategorized by Kenny Buntinx [MVP]

Carol Bailey has written an article about values to set for the key sizes and validity periods for the certificates required for native mode and out of band management in Configuration Manager that I want to share with you. 

Carol said : This has been a tough one for me to answer, because in the main, these values are external to Configuration Manager and they are PKI design questions with advantages and disadvantages for different values.  The higher the key size, the more secure the certificate is from attackers, but will require more processing to use.  The longer the validity period, the less certificate maintenance required (and potentially some service disruption), but the certificate is more vulnerable to being compromised.

Disclaimer:  The PKI-related information in this post is external to Configuration Manager, so you will not find this information in the Configuration Manager product documentation.  However, we realize that PKI is often new to Configuration Manager admins, and aim to share our knowledge and experience to help you be more successful with the product.

Until recently, the best advice I could offer customers without their own PKI consultants, was to follow the example of Microsoft default values on certificate templates that closely matched their own certificates.  Then check any certificate requirements in our documentation (for example, some certificates have a maximum supported key size), and take into account any overheads associated with renewal. 

However, at MMS in Vegas this year, Chris Adams and Ben Shy from Microsoft presented an excellent breakout session that shared their experience about how they implemented native mode and Internet-based client management in Microsoft.  This session was called "Demystifying Native Mode Security to Deliver Internet-based Client Management" and one slide I was particularly keen that they shared with customers was their strategy for deciding the key size and validity period.  Their numbers are based on RSA research and how long it would take an attacker to compromise a certificate.  So the higher the key size, the more secure the certificate is (but remember that this comes at the cost of extra processing). Their simple matrix that they presented at MMS looked like this:

  • Key length of 1024:  Validity period = not greater than 6-12 months

  • Key length of 2048:  Validity period = not greater than 2 years

  • Key length of 4096:  Validity period = not greater than 16 years

When you are deciding which values to use, we’ve already noted that you need to take into account any other restrictions – such as maximum supported key size by the application that uses the certificate.  However, you also need to take into account what your CA hierarchy can support. A CA cannot issue a certificate with a longer validity period than its own certificate.  This one is easy to remember, however, there’s also a ticking time limit because a CA cannot issue certificates with a validity period that is longer than its own remaining validity period.

This means that ideally, you want to plan your validity periods very carefully when designing your PKI – taking into account factors such as the type of certificates that you want to use, the applications that will use them, your company’s tolerance to security risks, and your renewal strategy.  However, in practice, you might have to fit your validity periods around your existing PKI design. 

Some examples:

  • If you want to use a validity period of 10 years for your site server signing certificate, this will not be possible if your issuing CA has a certificate with a validity period of 5 years.
  • If your issuing CA has a validity period of 5 years but has been up and running for 2 years, it will not be able to deploy certificates with a validity period of 4 years – until its own certificate is renewed.

Hope it Helps ,

Kenny Buntinx

SCUG.BE interviewed Jeremy Chapman on windows 7 deployment

8:07 pm in chopsticks, ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, events, Interview, OSD, SCCM 2007, SCCM 2007 R2 by Kenny Buntinx [MVP]


SCUG.BE interviewed Jeremy Chapman (Senior Product Manager in the Windows client enterprise team) on windows 7 deployment:



Have Fun,

SCUG.BE crew


SCUG.BE interviewed THE Jeff Wettlaufer at Techdays 2009 in Antwerp

9:11 pm in chopsticks, ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, Interview, Jeff Wettlaufer, SCCM 2007, SCCM 2007 R2, SCCM v.Next, techdays by

SCUG.BE interviewed the Jeff Wettlaufer (Sr. Technical Product Manager, System Center) at Techdays 2009 in Antwerp!





Have Fun,

The SCUG.BE Team