Once of the glaring deficiencies of SCCM OSD deployment (in my opinion of course) is the default behavior of an optional PXE advertisement.  Effectively if you want to have more than one pxe advertised task sequence the one that you DIDN’T execute will eventually pop up on every machine that has not run it before as an optional advertisement.  If the user clicks it and tries to run it (assuming your task sequence is set to do so) it will fail as it should be designed to only run within Windows PE.  Not a concern from a user accidentally rebuilding their own pc however not a viable option to have this popup on everyone and thus freak out the organization.  Well fortunately I have discovered a workaround for this issue.  It’s quite simple actually. 

This is assuming you have your “PXE” TS adverts and your “Push” TS Adverts separated.
*ALWAYS test any new changes in a lab environment prior to production implementation*
Right-Click your PXE advertisement and go to Properties.
Click the Advanced tab.
Select the radio button “This task sequence can only run on the specified client platforms”
Now find a platform that you will not have in your environment.  In my case I have selected “x64 Windows XP Professional SP1”.  I should not have this OS version on my network.  If I do it’s unsupported and the machine needs to be rebuilt as we currently do not support ANY x64 OS’s. 
Give that several minutes to propagate the changes.
You can then turn off the mandatory advertisement.  Your client will receive the advertisement however they will reject it based on the platform restriction.  This has no effect on your PXE building since the platform is not evaluated as part of the PXE build process.

You can now have multiple PXE adverts.  This is invaluable for testing build updates, etc.

One thing to keep in mind is that when you make your adverts optional the auto PXE boot (after selecting the network card as your boot device) goes away and you must press F12 (again) to initiate the connection.

I have found a workaround for this in my environment however the big disclaimer here is that this is NOT a supported solution from Microsoft.

F12 workaround:
On your WDS server(s) navigate to
D:\RemoteInstall\SMSBoot\x86
Make a copy of your pxeboot.com (the version that prompts you to press F12)
Delete the original pxeboot.com
Make a copy of pxeboot.n12 (the version that bypasses the additional F12 prompt)
Rename this copy to pxeboot.com
Flag this file as READ-ONLY.  If you do not do this the next reboot of your server will revert this file back.
Restart your WDS service and away you go.

Hope this helps someone else out there!!

Hello, It has been quite some time since I have updated any entries on this blog.  Seems like everyday I get more and more to do so less time to post blogs! 

Anyway, I currently typing this post from a Windows 7 Beta machine (ie8).  I rolled my production Dell Latitude E6500 to Windows 7 the day the public Beta was released and so far (barring one Explorer.exe crash) I have to say I am fairly jazzed.  All the Vista drivers loaded no problem and pound for pound it is using less resources than Vista did.  The performance in general really just feels much more solid than Vista and this is still Beta!  Some of the new functionality that is built into W7’s Areo is actually quite functional.   The new “Show Desktop” is pretty freakin cool. 

I am running this Beta in production right now joined to our domain so I will be putting it to the coals so to speak.  With this being Beta, barring any major screwups this could be the new generation OS I have been waiting for.  Its nice be excited again about a new desktop OS.  I was very disappointed with Vista sadly (as were many) so it appears that MS may be back on track.  Keeping my fingers crossed!

I’ll post back with more info after I give it a proper go.

I find myself using this quite often so I figured I would post here for a nice copy and paste for future uses. 
*Requires Windows 2003 Admin tools (adminpak.msi) to be installed

Export computer objects from a specified OU and all sub OU’s(careful of wordwrap):

dsquery computer “ou=laptops,ou=devices,ou=site,dc=subdomain,dc=domain,dc=com” -limit 0 -o samid >>Laptops.txt

-limit 0 tells the script to return ALL matching values (Default is 100)
-o samid tells the script to return the “friendly” name. (Default is the full DN)

Obviously replace the values with ones specific to your environment. 

Just thought I may be able to save someone else out there a headache..

Although I am typically a much bigger proponent of VMWare products in terms of performance I found out the hard way that building and capturing an image from VMWare (Server 2.0) works great in most cases for newer hardware. I also discovered that the “IDE” mass storage driver in VMWare Server 2.0 would not allow the image to boot on older hardware (think Latitude D800, 600, etc). I spent a couple of days trying to find a set of driver that I could inject to get the machines working but to no avail. I had used Virtual PC 2007 in the past to build and capture but the performance is so lacking compared to VMWare I figured I would start there first. Well a long story short, after I went back to using Virtual PC 2007 (SP1) as my base machine for build and capture my “older” hardware is now back to booting properly and my newer hardware continues to function by injecting their mass storage drives as needed.

The moral of the story? Use Virtual PC 2007 to build and capture your image! Then you can turn it off and use VMWare for everything else.

I have modified the PXEFilter.vbs that ships with MDT 2008 to automatically clear the last PXE advertisement of the machine that is PXE booting. This allows me to set a mandatory assignment for my OS Deployment and removes the requirement for field techs to have to open the admin console to re-image a machine via PXE.

The section I added was:

‘//————————————————————-
‘// Clear Last PXE Advertisement
‘//————————————————————-
On Error Resume Next
Dim resources
Dim InParams

‘ Set up the Resource array parameter.
resources = Array(1)
resources(0) = iResourceID

Set InParams = oSMS.Get(”SMS_Collection”).Methods_(”ClearLastNBSAdvForMachines”).InParameters.SpawnInstance_
InParams.ResourceIDs = resources

oSMS.ExecMethod “SMS_Collection”,”ClearLastNBSAdvForMachines”, InParams

if Err.number <> 0 Then
PXE.LogTrace “Failed to clear PXE advertisement for resource: ” & iResourceID
Else
PXE.LogTrace “Clear PXE Advertisement Completed successfully for resource: ” & iResourceID
End If

As any WSUS admin knows, the sync history for some unknown reason is not an option for cleanup using the built in cleanup wizard. This can result in excruciating load times when trying to view the sync history. Hopefully Microsoft will correct this in future releases however until then you can execute the following query against your WSUS DB to cleanup the Sync events.

DELETE FROM [SUSDB].[dbo].[tbEventInstance]
WHERE [EventID]=381 or [EventID]=382 or [EventID]=384 or [EventID]=386 or [EventID]=387

You may consider running this as a part of your monthly maintenance.

After upgrading my SMS 2003 SP2 site to SCCM 2007 SP1 the “SMS_SQL_MONITOR” service would fail to start stating Error 2: Cannot find the specified file.

I finally figured out (by stumbling across the website below) that this service is an SMS 2003 service only and is not required for SCCM. Apparently this is a bug in the Setup that doesn’t remove this service for you..

*I should also note that I verified that this service does not exists in my clean install of SCCM in my Lab.

Instructions on removing this service here:
http://blogs.technet.com/alipka/archive/2008/07/22/sccm-sp1-slipstream-setup-on-sms-2003-sp2-sp3-site-fails-to-remove-sms-sql-monitor-service.aspx

If anyone has used Sysprep with XP on a machine that uses an Intel Graphics chipset you have likely ran into the dreaded hang during mini-setup when plug and play installs the graphics driver. (Sits at the please wait screen and must be manually rebooted to continue)

Microsoft offers a hotfix for this (must be requested via the web form or through calling PSS)
http://support.microsoft.com/default.aspx/kb/883667

It is effectively a single dll file that needs to be replaced.

12-Aug-2004 17:50 5.1.2600.2505 247,808 Newdev.dll SP2QFE

I have tested and it definately seems to do the trick.

Some great resources around virtualizing applications:

The App-V Blog:
http://blogs.technet.com/softgrid/default.aspx

Application Virtualization Operations Guide
http://blogs.technet.com/softgrid/archive/2007/11/13/softgrid-operations-guide-part-1.aspx
http://blogs.technet.com/softgrid/archive/2007/11/14/softgrid-operations-guide-part-2.aspx

List of applications that can be virtualized
http://blogs.technet.com/softgrid/archive/2007/09/27/list-of-applications-that-can-be-virtualized.aspx

Virtualworld Blog
http://blogs.technet.com/virtualworld

I have run into scenerios where I needed access to the Windows Installer service while in Safe Mode. You may be suprised to know that this service is not enabled by default. The following info will get it back for you:

To start Windows Installer in Safe Mode:
1. Restart your computer and press F8 before the Boot Menu or splash screen.

2. Open a CMD.EXE window.

3. Type the following commands and press Enter:

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer” /VE /T REG_SZ /F /D “Service”
net start msiserver

NOTE: You can use this technique to uninstall an application in Safe Mode.