SCCM 2007: Remove obsolete PXE service point from ‘component status’

May 30, 2013 2 comments

Recently I had an issue with a PXE service point which was always coming back in the component status with status critical. The component was already removed from the Site Systems and also from the registry but It didn’t want to go away from the Component Status.

CriticalPXEComponent

Firstly I tried to remove it by deleting the failed status records via an SQL query described in the following blog: http://oleskovgaard.blogspot.be/2011/10/eliminated-distribution-points-still.html

But it kept coming back after a while.

The solution here is to modify the record in the Summarizer_SiteSystem table.

  • Open the SQL Server Management Studio
  • Open the SCCM Database
  • Open the Tables
  • Right click on the table dbo.Summarizer_SiteSystem & select open table.
  • Change the Replicate value to -1 for the failing PXE Site System by right clicking the row.
  • Close the SQL Server Management Studio and wait for one hour. The failed PXE Service point will be disappeared from the Component Status.

Summarizer_SiteSystemTable

Please note that this is not supported by Microsoft and make sure that you have a proper backup before modifying the SQL Database.

 

Advertisements
Categories: SCCM 2007 / 2012

SCCM 2007: Failed to add driver to driver store

May 27, 2013 Leave a comment

Recently I was troubleshooting a strange issue with OSD Driverpacks in SCCM 2007. I would like to share the solution for my issue because I spent a lot of time on this issue and there is not a lot of info on the Internet. The SCCM 2007 environment that I was troubleshooting was with MDT 2010 integration.

Every driver package was failing to apply drivers to a Windows 7 x86 Edition. I first thought it was a malfunctionning driver because all driver packages were downloading fine but were not injecting the drivers to the Windows 7 driver store. I changed the driver packages to only a few essential drivers but it kept failing.

I had the following errors in the SMSTS.log:

Failed to add driver to driver store. Code 0x8022001b
Failed to provision driver. Code 0x8022001b

DriverpackError

Further in the DISM.log file I found the following:

8022001b [Error,Facility=FACILITY_STATE_MANAGEMENT,Code=27 (0x001b)] #28# from CChildContextStore::CreateListSetting(path = /settings/DriverPaths, settingName = PathAndCredentials[@keyValue=”1″], enumerator = @0x346f08, settingType = 16 (0x00000010))[gle=0x80004005]

DriverpackError_Dism

The Dism.log file contains all info about injecting drivers to Windows 7 because WINPE is using DISM.exe to inject the drivers to the Windows 7 drivers store.

So I tried a lot of things to solve this but I ended up to solve this via the following way:

  • Generate a new MDT 2010 WINPE boot image.
  • Launch a new image capture with the newly generated WINPE image.
  • Create a new Operating System Image Package.
  • Deploy the New image with the newly generated WINPE image.

Firstly I already created a new image but with the old WINPE image but this didn’t solve the problem. It’s very important to create a completely fresh WINPE image to solve this issue. I am not sure what exactly the problem but it must be somewhere in the WINPE image.

My advice is also don’t use special characters in the names of the driver packages and folder names.

Hope this can help someone.

Categories: SCCM 2007 / 2012

SCCM 2007: OSD error – Must be running in full OS

May 1, 2013 3 comments

This is a quick solution for an error during an OS deployment task sequence within SCCM 2007. I had encountered the following errors:

The step … must be running in full OS
Error code 8000700032

FullOS_Error

I had implemented a task to install the VMware tools during the driver installation which caused this error because this was a normal package. The solution here is to move the task under the “Setup Windows and configMgr” task. The SCCM client must be installed first before you can install properly software like the VMware tools.

tasksequence

Below is the install command for a successful VMware tools installation during the OS Deployment task sequence:

msiexec.exe /i “VMware Tools.msi” /QN ADDLOCAL=ALL REBOOT=ReallySuppress

Categories: SCCM 2007 / 2012

DFS mapping error: Refers to a location that is unavailable

February 20, 2013 2 comments

Last week I experienced some strange behaviors with offline files in combination with DFS. In most environments is DFS really common and used for network mappings, roaming profile, homedrive,.. .

The initial issue was that users experienced random access issues to DFS mappings which solved themselves after some time.

Users get an error like: Drive x refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location.

DFS_Error

In the beginning I thought that this was an issue with one of the DFS Namespace servers. Mostly are random access denied issues caused due a permission difference on one of the DFS roots.

When the issue occurred I started trying to access the DFS share through different locations:

  • client could not connect to “\\domain.com\dfsroot”
  • client could connect to “\\domain\dfsroot”
  • client could connect to “\\DCA\dfsroot”
  • client could connect to “\\DCB\dfsroot”

Apparently only the “\\Domain.com\” was not accessible. So I also enabled show hidden files and protected files and then I saw that only the Homedrive of the user was available because this was made offline. But what I really found strange was that “\\domain\dfsroot” was just working. I discovered that on desktops the access issue was not happening because offline files were not enabled on the desktops.

After some research on the Internet that Offline Files does not distinguish DFS paths from UNC paths:  Technet blog

So what happens on Windows 7 client: Offline files sync in the background and there is by default a slow-link detection mechanism.

  • If the offline file feature discovers that the network is slow it will work offline (Slow-Link mode)
  • Offline file feature thinks that \\domain.com is the fileserver so it will break the communication to \\domain.com
  • All other DFS mappings based on \\domain.com become unavailable
  • The DFS mappings will become online again if the offline file feature detects fast network again

There is not really a nice solution for this but here are some possible solutions:

  • Disable Slow-Link mode via Group Policies (it will not solve mapping issue when the client really lose it’s connection for a short time)
  • Use UNC paths as network mappings
  • Map network drives as \\Domain\dfsroot (A bit cheating with DFS : so without .com)

I don’t know yet if the offline file feature on Win8/Server 2012 can work with DFS paths.

SCCM 2007: Move SMSPKG folder

December 22, 2012 1 comment

By default is the SMSPKG folder stored on the C-Drive which can grow a lot overtime when you are using a lot of packages. The SMSPKG folder are pre-packaged content files that are needed for distribution manager to send out content between sites and if you have opted for the option to use compressed source on a package. I faced also disk space problems on the C-Drive due this folder. In this post I will show you how to move this folder safely to another disk without issue. You can face distribution issues if you delete content or just change the location in the SCCM console.

The first option you can do is disable the compressed source feature on all your packages and delete the content but this can be very time-consuming. And the complete content of the packages will be send to the distribution points by a package modification otherwise are just the modifications copied.

My recommendations about this:

  • Change the location in Site name – Site Settings – Component configuration – Software Distribution – Properties

    SW_Distribution

  • Copy all content from the old SMSPKG folder to the newly created folder on the other drive. The folder will be created automatically by SCCM.
  • Get the sharename of the folder on the C-Drive and add this share name on the SMSPKG folder on the new location.

    SMSPKG_Share

  • Share permissions: Grant everyone read permissions

I think that this is the most easy way to perform this because I have seen solutions by modifying the SQL database. Existing packages still using the SMS_CPSC$ share and new packages will use the SMS_CPSF$ share.

Categories: SCCM 2007 / 2012

Windows 7: Remote assistance – Black screen during elevated rights

December 22, 2012 Leave a comment

By default you get a black screen when you offer remote assistance and run for example an application with elevated rights which is frustrated for IT support. In this post I will show you the two actions you must take to overcome this unpleasantness.

What Microsoft says about this:
It is not recommended that you start a program as an administrator in a Remote Assistance session. In this situation, the user can disconnect the Remote Assistance session at any time. Then, the user can continue to use administrative rights to run the program. To perform administrative tasks on a client computer, you may use a Remote Desktop Connection. 

To overcome this:

  • Change UAC policy

    Computer Policies\Windows Settings\Local Policies\Security Options\User Account Control\User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

    UAC_Policy

    If you enable this policy setting, requests for elevation are automatically sent to the interactive desktop (not the secure desktop) and also appear on the remote administrator’s view of the desktop during a remote assistance session. This allows the remote administrator to provide the appropriate credentials for elevation.

    More info: http://technet.microsoft.com/en-us/library/dd851479.aspx

Categories: Windows XP / 7

Windows 8: VMware Workstation MSI failed

November 10, 2012 4 comments

VMware Workstation 9 on Windows 8 was a struggle for me. The x64 MSI of VMware workstations was always failing with the same error message  ‘vmwareworkstation_x64.msi failed’. I tried cleaning up the temp folder, running the exe with an other account, investigating the msi log, etc..

I ended up in following the 1308KB of VMware. first I tried install cleaner(VMware_Install_Cleaner.zip) but this didn’t solve the problem for me. The issue was solved after following the “Manually cleaning a Windows system” steps by deleting specific folders & files and registry keys.

VMware link KB1308

Categories: Windows 8