Today I ran into an issue that software updates and applications failed to install during a task sequence (TS). This only was applicable to ‘known’ agents. Unknown agents or agents which are receiving the task sequence for the first time doesn’t have the problems.
OSD
Hiding the task sequence progress dialog box
StandardLast week I had a script which generated popup during my task sequence. This popup was visible behind the task sequence progress window. I searched for a solution to hide the task sequence progress window and found a post from Michael Niehaus on the TechNet blogs. The link to the original post is:
SCCM 2012: OSD Computername from SMS database not being used
StandardToday I investigated a issue related to Operating System Deployment in ConfigMgr 2012. During the Deployment of Windows 7 the computer didn’t receive the computer name from the SMS database. Every deployment was ending with a computer name which sounds like: ‘MININT-XXXXX’. We are using Task Sequence Media to receive the Task Sequence. After investigating the log files I could only found this related settings:
After searching through all the steps in the TS I couldn’t find a solution. I searched through the Microsoft forums and found this topic: http://social.technet.microsoft.com/Forums/en-US/configmanagerosd/thread/63909599-7618-406e-9655-75590689dedf. The BUG and workaround suggested was in my case also the solution. Use during creation of the Task Sequence media for ‘Site-based media’ instead of ‘Dynamic Media’. See below the screenshot:
I have not tested this BUG in the Beta of SP1. I will update this topic as soon as the results are known.
UPDATE: This bug has been fixed after installing ConfigMgr 2012 CU2
SCCM 2012 OSD: Failed to Run Task Sequence (0x80004005)
StandardRecently I moved from ISP. On the new router it’s not possible to change the DNS servers for DHCP clients. Therefore my router is the DNS server and cannot find my domain servers with the FQDN, NETBIOS isn’t a problem. I started a new Operating System deployment task and the client reported the following error, right after the start of WinPE and before getting the policies:
After investigating the SMSTS.LOG I found out that the MP cannot be contacted through the FQDN. The easiest solution is to enter a static IP, but the idea of entering a static IP for each new deployment is not that dynamic. My best workaround was to change the hosts file of the Boot Image and add the FQDN of the MP. See below the steps which needs to be taken to add the MP to the hosts file of the Boot Image
1. Mount the WinPE BootImage with DISM
2. Edit the Hosts file in .WindowsSystem32DriversEtc and add the entry of the MP
3.Unmount the WinPE BootImage with DISM and commit changes
4. Update the Distribution Points with this new Image.
5. Done!
SCCM 2007 R2 SP2: PXE Error (PXE-T04: Access violation)
StandardToday I had a very strange PXE error at a customer site. Recently I installed I fresh SCCM 2007 environment and we are now in the process of configuring this environment. Today we started with configuring PXE. At the Customer site they use a Linux DHCP server serving the clients. At the DHCP server we made the following exclusion:
filename "/SMSBoot/x86/wdsnbp.com";
next-server;
After we started the client we run into the following error:
PXE-T04: Access violation.
PXE-E36: Error received from TFTP server
After getting this error we connected from a other client station to the SCCM Server via TFTP and tried to download wdsnbp.com file. At this client we got also the same error. When we replaced the “/” with “” it works from the client site. But when booting from PXE the error still comes. I searched on the Internet and was pointed in the right direction. I changed the following Register Key/Value on the SCCM Server:
Original:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWDSServerProvidersWDSTFTP]
ReadFilter=
boot*
tmp*
SMSBoot*
SMSTemp*
SMSImages*
Changed to:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWDSServerProvidersWDSTFTP]
ReadFilter=
boot*
tmp*
SMSBoot*
SMSTemp*
SMSImages*
/boot/*
/tmp/*
/SMSBoot/*
/SMSTemp/*
/SMSImages/*
As final step I restarted the WDS Server service and the problem was Solved. So the problem was the way Linux is slashing file paths. I hope that this information helps people to solve this kind of problems. The article which pointed me in the right direction can be found here.