Quantcast
Channel: The Official Configuration Manager Support Team Blog
Viewing all 715 articles
Browse latest View live

Creating OSD USB deployment media in System Center Configuration Manager 2007 fails with "The parameter is incorrect"

$
0
0

KBJust a heads up on a new ConfigMgr 2007 Knowledge Base article we published today.  If you do any work with Operating System Deployment (OSD) then you'll want to check this one out:

=====

Symptoms

When trying to create Stand-alone media, Bootable media, or Capture media on a USB Flash drive via the Microsoft System Center Configuration Manager 2007 (ConfigMgr 2007) console, the Task Sequence Media Wizard fails with the following message:

Error creating media. Error message is: The parameter is incorrect.. Please refer to CreateTSMedia.log to get details.

Inspecting the CreateTsMedia.log shows the following errors:

Beginning media generation CreateTsMedia
Failed to create media (0x80070057) CreateTsMedia
CreateTsMedia failed with error 0x80070057, details="" CreateTsMedia

Creating the USB media in a ConfigMgr 2007 console running on other PCs may be successful and may not reproduce the problem.

Cause

The problem is a known issue with ConfigMgr 2007 SP2 and older, including R2 and R3, when the following conditions exist on the PC running the ConfigMgr 2007 console:

1. A mapped network drive exists on the PC

2. The PC's hard drive has a partition with no drive letter attached to it

Condition #2 above is very common in Windows 7 and Windows Server 2008 R2 since the default installation of Windows 7 creates the boot partition as a "hidden" system partition with no drive letter attached to it. It is also a common configuration on PCs that have been encrypted with BitLocker. For this reason the issue is seen most often on Windows 7, Windows Server 2008 R2, and PCs that have drives encrypted with BitLocker.

Resolution

To work around the problem, take one of the following two actions before trying to create the USB media via the ConfigMgr 2007 console:

1. Temporarily disconnect mapped network drives.

or

2. Via the Computer Management console, temporarily assign a drive letter to the "hidden" partition.

Only one of the above two actions needs to be taken. Both do not need to be taken.

Once the USB media has been created, mapped network drives can be reconnected and/or the assigned drive letter can be removed from the previously hidden partition.

=====

For the latest version of this article see the link below:

KB2471018 - Creating OSD USB deployment media in System Center Configuration Manager 2007 fails with "The parameter is incorrect"

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

clip_image001 clip_image002


System Center Updates Publisher downloads fail with error 0x800b0004 in System Center Configuration Manager 2007

$
0
0

KBJust a heads up on another Configuration Manager KB article we published today.  This one involves error 0x800b0004 and System Center Updates Publisher :

=====

Symptoms

The Microsoft System Center Configuration Manager 2007 (ConfigMgr 2007) System Center Updates Publisher (SCUP) component may fail to synchronize updates.  Entries similar to the following will be logged in PatchDownloader.log:

Download destination = \\servername\Source\Contoso Updates\04dd8265-4c25-4e7c-ba2d-2f29cbe4bd3e.1\updatename.exe . Software Updates Patch Downloader 12/2/2010 11:04:30 AM 3576 (0x0DF8)
Contentsource = ftp://ftp.contoso.com//pub/updatename.exe . Software Updates Patch Downloader 12/2/2010 11:04:30 AM 3576 (0x0DF8)
Downloading content for ContentID = 25530,  FileName = updatename.exe. Software Updates Patch Downloader 12/2/2010 11:04:30 AM 3576 (0x0DF8)
Download ftp://ftp.contoso.com//pub/updatename.exe to C:\Users\administrator\AppData\Local\Temp\CABF417.tmp returns 0 Software Updates Patch Downloader 12/2/2010 11:04:30 AM 4080 (0x0FF0)
Cert revocation check is disabled so cert revocation list will not be checked. Software Updates Patch Downloader 12/2/2010 11:04:30 AM 4080 (0x0FF0)
To enable cert revocation check use: UpdDwnldCfg.exe /checkrevocation Software Updates Patch Downloader 12/2/2010 11:04:30 AM 4080 (0x0FF0)
Authentication of file C:\Users\administrator\AppData\Local\Temp\CABF417.tmp failed, error 0x800b0004 Software Updates Patch Downloader 12/2/2010 11:04:30 AM 4080 (0x0FF0)

Cause

This error can occur if a proxy server or other networking device returns an HTML error for the file request.  SCUP attempts to read the digital signature of the temporary file and fails.  This error does not occur in cases of connectivity failure.

Resolution

Investigate any upstream proxies, firewall servers, or other network devices that may be returning custom error messages.

More Information

To verify that a server is in this condition, either take a network capture while the download is being performed or use these steps to manually simulate the download:

  1. Log on to the server with administrative credentials.
  2. Download psexec.exe from http://live.sysinternals.com/psexec.exe.
  3. Close any Internet Explorer windows
  4. Launch an elevated command prompt and run the command:  psexec /s /i cmd /c start <URL> where <URL> is the FTP or HTTP URL specified in the PatchDownloader.log file.

=====

For the latest version of this article see the link below:

KB2477936 - System Center Updates Publisher downloads fail with error 0x800b0004 in System Center Configuration Manager 2007

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

clip_image001 clip_image002

How to easily test your remote SQL connectivity

$
0
0

networkMicrosoft's own Steve Rachui explains how to quickly and easily test remote SQL connectivity using any account you like.  This is a neat trick that will surely prove useful when working with a wide variety of products.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

clip_image001 clip_image002

Configuration Manager 2007 client downloads hang or take a very long time when your package contains many folders and files

$
0
0

toolsignHere's an interesting issue I ran into the other day and I thought I'd post it here in case anyone happened to see it.  The issue is one where if you have System Center Configuration Manager 2007 running on Windows Server 2008 R2 with WEBDAV 7.5, clients doing downloads using BITS can either appear to hang or they may just take a very long time downloading updates when your package contains many folders and files. 

Note: This is actually a known issue in WEBDAV 7.x that was resolved with a hotfix in the non-R2 version of Windows Server 2008.  Here is the hotfix I'm referring to: 

KB957001 - A hotfix rollup is available for the out-of-band WebDAV module for IIS 7.0 : http://support.microsoft.com/default.aspx?scid=kb;EN-US;957001.

It does seem that this issue is the same as the one described in KB957001, however since we were running on IIS 7.5 the hotfix was not applicable since it is an older version than what is already is on the Windows Server 2008 R2 system.

After discussing this issue with the development team, while the issue itself is corrected in WEBDAV 7.5 it still needs to be configured. 

Note: They also provided this link for more information: http://www.iis.net/ConfigReference/system.webServer/webdav/authoring

The setting that can affect the behavior we we're seeing above is the ‘maxAllowedXmlRequestLength’ attribute.  It is not exposed in the User Interface but you can configure it with the appcmd.exe utility to set the PROPFIND response body to 30MB:

appcmd.exe set config "Default Web Site" -section:system.webServer/webdav/authoring /maxAllowedXmlRequestLength:31457280 /commit:apphost

By configuring this we are configuring the value above the default which is 4MB as documented in KB957001.  Note that this is the XML response size, not the number of files or the size of the files.

Increasing this number to 30MB definitely improved the performance for some clients as it went from taking 8 to 12 hours to download the package to taking from 2 to 5 hours on some clients.  Despite the improvement on these clients, other clients still took as long as 10 hours to download the package.  As an optional workaround to increase performance further you can build your package into a single MSI file using a third party packaging tool which should offer a dramatic improvement.

Hope this helps,

Clifton Hughes | Senior System Center Support Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

clip_image001 clip_image002

Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007

$
0
0

toolsign

Note: The section titled How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point was updated with two additional steps (19 and 20) on 1/6/2011.

=====

This is a general guide on properly setting up and troubleshooting the System Center Configuration Manager 2007 (ConfigMgr 2007) PXE Service Point. 

Common errors that are seen at the PXE boot screen when the PXE Service Point is either not configured properly or experiencing problems are the following:

PXE-E53: No boot filename received
PXE-T01: File not found
PXE-E3B: TFTP Error - File not Found
PXE-E55 Proxy DHCP Service did not reply to request on port 4011

However the error messages can vary depending on the PXE implementation on the client PC.  Another common symptom is that the Windows Deployment Services Server (WDS) service will not start.

To resolve these issue and to prevent them from occurring in the first place, follow the guide below  This guide is broken down to the following sections:

- Setting Up IP Helpers

- How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point

- Reinstalling WDS And The PXE Service Point

- Testing The PXE Service Point

- Monitoring And Troubleshooting The PXE Boot

The guide is written in chronological order of the actions that need to be taken properly get a ConfigMgr 2007 PXE Service Point working and operational. Refer to the appropriate sections as needed.

 

Setting Up IP Helpers

If the DHCP server, the client PC, and the ConfigMgr 2007 server are running WDS and the PXE Service Point are all on the same subnet or vlan, please proceed to the section "How To Properly Install and Set Up The PXE Service Point". Otherwise, if either the DHCP server, the client PC or the ConfigMgr 2007 server is running WDS and the PXE Service Point are on separate subnets or vlans, which is usually the case in most environments, the first step to take before trying to install and configure the PXE Service Point and WDS is to set up IP Helpers on the routers. How to do this varies depending on the router hardware manufacturer but the general overview is outlined at the below link:

Configuring Your Router to Forward Broadcasts
http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Updating

For further information on how to properly configure IP Helpers on the routers, please contact the hardware manufacturer of the router.

IP Helpers are necessary because the PXE request generated by the client PC is a broadcast that does not travel outside of the local subnet or vlan. It only stays within the local subnet or vlan. If the DHCP server and/or the WDS/PXE Service Point server are not on the subnet or vlan as the client PC, they will not see or hear the PXE request broadcast from the client PC and therefore will not respond to the PXE request. To have the PXE request broadcast transverse between subnets or vlans, the PXE request broadcast needs to be forwarded by the router to the DHCP and WDS/PXE Service Point servers so that they can properly respond to the client PC's PXE request.

An alternative to using IP Helpers is setting DHCP Options on the DHCP server, specifically DHCP Options 60 (PXE Client), 66 (Boot Server Host Name), and 67 (Bootfile Name). However, DHCP Options can be problematic and may not work reliably or consistently. Furthermore the use of DHCP Options to control PXE requests is not supported by Microsoft. Therefore the only recommended and supported method of PXE booting client PCs that are on a different subnet than the DHCP or WDS/PXE Service Point servers is the use of IP Helpers.

For additional information regarding DHCP Options not being recommended or supported please see the below articles:

Using DHCP Options 60, 66, and 67
http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Using

PXE clients computers do not start when you configure the Dynamic Host Configuration Protocol server to use options 60, 66, 67
http://support.microsoft.com/kb/259670

The only exception where a DHCP Option needs to be used is when DHCP and WDS reside on the same server. In this instance, DHCP Option 60, and only DHCP Option 60, needs to be set. DHCP Options 66 and 67 should still NOT be set in this scenario. For more information, please see the section "Windows Deployment Services (WDS) and DHCP" in the following article:

Planning for PXE Initiated Operating System Deployments
http://technet.microsoft.com/en-us/library/bb680753.aspx

It is IMPERATIVE that before continuing that it has been verified that the routers have IP Helpers configured AND that the DHCP server does NOT have DHCP Options 60, 66, or 67 configured. Not meeting both of these criteria will cause the PXE Service Point not to work correctly. When checking DHCP options, make sure to check options at both the server and scope levels.

In certain instances, configuring DHCP Options 60, 66, and 67 may make it appear that the PXE boot process is proceeding further along than before these options were configured, but in reality it just proceeds further down an incorrect path, ends up giving different error messages, and ends up failing.

How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point

The following section lists the step to ensure that that a NEW instance of the PXE Service Point is set up and configured properly. If Windows Deployment Services (WDS) and/or the PXE Service Point has been previously installed, even if it never worked, follow the instructions under the section "Reinstalling WDS And The PXE Service Point" instead:

1. If needed, make sure that IP Helpers have been configured. Additionally, make sure that DHCP Options 60, 66, 67 have NOT been configured. See the section "Setting Up IP Helpers" for additional information.

2. Install, but DO NOT configure, Windows Deployment Services (WDS) on the server that will host the PXE Service Point.

  • If using Windows Server 2003, WDS is installed via the Add/Remove Windows Components in the Add/Remove Control Panel.
  • If using Windows Server 2008 or newer, WDS is installed via Roles in Server Manager. When installing in Windows Server 2008 or newer, make sure that both the Deployment Server and Transport Server are installed.

3. If prompted to do so after WDS has finished installing, reboot the server.

4. Once the server has restarted, DO NOT try to manually configure or start the WDS service.

5. In the ConfigMgr 2007 Admin Console, navigate to "Site Management" --> <Site_Code> --> "Site Settings" --> "Site Systems".

6. If the server where the PXE Service Point is going to be installed already exists under "Site Systems", right click on the server and choose "New Roles".  Otherwise right click on "Site Systems" and choose "New" --> "Server".

7. In the "General" page of the wizard, make sure that the NETBOIS and FQDN name of the server are correct and then click on the "Next >" button.

8. In the "System Role Selection" of the wizard, check "PXE service point" and then click on the "Next >" button.

9. Review the "PXE Service Point Configuration" dialog windows and then click on the "Yes" button.

10. In the "PXE - General" window, configure the appropriate options as desired and then click on the "Next >" button.

11. In the "PXE - Database" window, change any options as needed. In most cases, leave settings at their default in this window. Click on the "Next >" button.

12. Click on the "Next >" button and then on the "Close" button.

13. On the server where the PXE Service Point is being installed, navigate to the ConfigMgr 2007 site server log location using Windows Explorer. Usually the log location will be under one of the following paths:

  • 32bit servers
    <drive_where_ConfigMgr_is_installed>\Program Files\Microsoft Configuration Manger

 

  • 64bit servers
    <drive_where_ConfigMgr_is_installed>\Program Files (x86)\Microsoft Configuration Manger\Logs

 

  • 32bit or 64bit servers
    <drive_where_ConfigMgr_is_installed>\SMS

14. Once the log directory has been located in Step 13, open the log file PXESetup.log using SMS Trace/Trace32.exe.  Monitor this log and verify that the PXE Service Point installed correctly. It may take a few minutes for the installation to start and finish successfully. If this is the first time the PXE Service Point is being installed on the server, it may take a few minutes for the PXESetup.log to appear and be created.

Once installed correctly, the last lines in the log should be "pxe.msi exited with return code: 0" and "Installation was successful." Verify that the line is for the current date and time frame.

In some circumstances, the last lines will read "pxe.msi exited with return code: 3010" and "Installation was successful, but a reboot is required." If this is the case, make sure to reboot the server before continuing.

Do NOT proceed until confirmation has been received in the PXESetup.log that installation has been successful.

15. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Boot Images".

16. If BOTH the x64 and x86 Boot Images are not already on any standard Distribution Point (DP), make sure to put both Boot Images on at least one standard DP. Monitor the "Package Status" node and ensure that both the x64 and x86 Boot Images properly install on the standard DP.

17. Place BOTH the x64 and x86 Boot Images on the SMSPXEIMAGES$ DP on the server where the PXE Service Point was created. Monitor the "Package Status" node and ensure that both the x64 and x86 Boot Images properly install on the SMSPXEIMAGES$ DP.

18. Once the Boot Images have installed on the SMSPXEIMAGES$ DP, open the Services console on the PXE Service Point server and ensure that the Windows Deployment Services Server service has started. Additionally make sure that the RemoteInstall folder has been created on the root level of the one of the drives of the server.

19. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Task Sequences". Right click on each Task Sequence that will be deployed via PXE and choose "Properties". Click on the "Advanced" tab and ensure that the option "Use a boot image:" is checked and that an appropriate boot image for that Task Sequence is selected.

20. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Software Distribution --> "Advertisements". Right click on each Advertisement for Task Sequences that will be deployed via PXE and choose "Properties". Under the "General" tab make sure that the option "Make this task sequence available to boot media and PXE" is checked.

Notes:

1. When the PXE Service Point is installed, it will automatically configure WDS and create the RemoteInstall folder. Once configured, the PXE Service Point installation will then automatically start the WDS service. For this reason, manual configuration of WDS in the Windows Deployment Services console is NOT necessary and should not be performed.

The only exception to this rule is when DHCP and WDS reside on the same server. In these cases, consult the section "Windows Deployment Services (WDS) and DHCP" in the following article:

Planning for PXE Initiated Operating System Deployments
http://technet.microsoft.com/en-us/library/bb680753.aspx

2. Once the PXE Service Point has configured and started WDS, the Windows Deployment Services console will still show a yellow exclamation mark and display the message "Windows Deployment Services is not configured". This is normal and does not indicate a problem. No action or configuration should be taken in the Windows Deployment Services console.

3. Regardless of the architecture of the Windows OS being deployed, it is IMPERATIVE that BOTH the x86 and x64 Boot Image are on BOTH a standard DP and the SMSPXEIMAGES$ DP. Make sure to verify that this has been done.

4. Do NOT place any other types of packages other than Boot Images in the SMSPXEIMAGES$ DP. Placing any other type of packages in the SMSPXEIMAGES$ DP, especially OS images, may cause WDS not to work correctly.

 

Reinstalling WDS And The PXE Service Point

In certain scenarios, especially ones where WDS and the PXE Service Point were initially installed or configured incorrectly, the best course of action is to uninstall the PXE Service Point and WDS, delete all previous configurations, and then reinstall:

1. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Boot Images".

2. Under each Boot Image, click on the "Distribution Points" node. On the right hand panel, right click on the "\\<Server_Name>\SMSPXEIMAGES$" DP and then choose "Delete" (where <Server_Name> is the name of the server where the PXE Service Point and WDS is being reinstalled). If the Boot Image is installed on the standard DP, it is NOT necessary to also delete the Boot Image from the standard DP.

3. Under each Boot Image that was deleted, monitor the "Package Status" node under the Boot Image to ensure that the Boot Image is removed from the SMSPXEIMAGES$ DP. To verify, check the "Package Status" node under the first "Package Status" node. Once the Boot Image has been successfully deleted from the DP, "Source Version", "Targeted", and "Installed" will all be 0.

4. Make sure that no other packages are on the SMSPXEIMAGES$ DP. To check if there are any other packages on the SMSPXEIMAGES$ DP, on the server where the PXE Service Point is being uninstalled, navigate to the folder RemoteInstall\SMSImages\SMSPKG. The RemoteInstall folder will be on the root level of one of the drives of the server. If the folder is empty, all packages have been removed. If the folder contains subfolders, there are additional packages on the SMSPXEIMAGES$ DP that need to be removed:

a. To determine which packages are on the DP, copy down the folder names. The folder names correspond to the Package ID of the package that is on the DP.

b. In the ConfigMgr 2007 Admin Console, navigate to "System Status" --> "Package Status". On the right hand panel all of the packages in the environment will be listed. On the far right last column the Package ID will be listed. Match up the Package ID obtained in Step 1
with the Package Name.

c. Based on the Package Name obtained in the Step 2, locate the package under one of the following nodes in the ConfigMgr 2007 console:

  •  
    • "Computer Management" --> "Software Distribution" --> "Packages"
    • "Computer Management" --> "Operating System Deployment" --> "Operating System Images"
    • "Computer Management" --> "Operating System Deployment" --> "Operating System Install Packages"
    • "Computer Management" --> "Operating System Deployment" --> "Driver Packages"
    • "Computer Management" --> "Software Updates" --> "Deployment Packages"

d. Under each package, click on the "Distribution Points" node. On the right hand panel, right click on the "\\<Server_Name>\SMSPXEIMAGES$" DP and then choose "Delete" (where <Server_Name> is the name of the server where the PXE Service Point and WDS is being reinstalled).

e. Under each package that was deleted, monitor the "Package Status" node under the package to ensure that the package is removed from the SMSPXEIMAGES$ DP. To verify, check the "Package Status" node under the first "Package Status" node. Once the package has been successfully deleted from the DP, "Source Version", "Targeted", and "Installed" will all be 0.

f. Once all of the packages have been deleted, check the RemoteInstall\SMSImages\SMSPKG folder on the server where the PXE Service Point is being uninstalled and and ensure that it is empty.

5. On the server where the PXE Service Point and WDS are being deinstalled, open the Services console. Locate the "Windows Deployment Services Server" service, right click on it, and select "Stop". If the service is already stopped, proceed to Step 6.

6. In the ConfigMgr 2007 Admin Console, navigate to "Site Management" --> <Site_Code> --> "Site Settings" --> "Site Systems".

7. Under "Site Systems", click on the server where the PXE Service Point is being uninstalled.  On the right hand panel right click on "ConfigMgr PXE service point" and choose "Delete". In the "Confirm Delete" dialog box, click on the "Yes" button.

8. On the server where the PXE Service Point is being uninstalled, navigate to the ConfigMgr 2007 site server log location using Windows Explorer. Usually the log location will be under one of the following paths:

  • 32bit servers
    <drive_where_ConfigMgr_is_installed>\Program Files\Microsoft Configuration Manger

  • 64bit servers
    <drive_where_ConfigMgr_is_installed>\Program Files (x86)\Microsoft Configuration Manger\Logs

  • 32bit or 64bit servers
    <drive_where_ConfigMgr_is_installed>\SMS

9. Once the log directory has been located in Step 8, open the log file PXESetup.log using SMS Trace/Trace32.exe. Monitor this log and verify that the PXE Service Point uninstalled correctly. It may take a few minutes for the deinstallation to start and finish successfully. Once uninstalled correctly, the last line in the log should be "SMSPXE deinstall exited with return code 0", "Deinstallation was successful.", and "Removing PXE Registry." Verify that the lines are for the current date and time frame.

If the deinstall of the PXE Service Point never kicks off, check the sitecomp.log on the parent site server to determine why it was not able to start the deinstall. In most cases it is due to file in use issues, which usually can be resolved by stopping the WDS service (Step 5).

Do NOT proceed until confirmation has been received in the PXESetup.log that deinstallation has been successful.

10. Uninstall Windows Deployment Services (WDS) on the server:

a. If using Windows Server 2003, WDS is uninstalled via the Add/Remove Windows Components in the Add/Remove Control Panel.

b. If using Windows Server 2008 or newer, WDS is uninstalled via Roles in Server Manager.

11. Reboot the server where WDS and the PXE Service Point were just deinstalled.

12. Once the server reboot completes and the server comes back up, locate the RemoteInstall folder on the root level of each of the drives of the server. If it exists on the drive, rename the RemoteInstall folder (i.e. RemoteInstallOld). On most servers, only one of the drives will have a RemoteInstall folder. However if multiple instances of the RemoteInstall folder exist, make sure to rename each instance.

If when renaming the RemoteInstall folder you receive one of the below messages:

Windows Server 2008/Windows Server 2008 R2
This folder is shared with other people
If you rename this folder, it will no longer be shared.
Folder: <drive_letter>\RemoteInstall
Share Name: REMINST

or

Windows Server 2003
You are sharing <drive_letter>:\RemoteInstall\SMSIMAGES as SMSPKEIMAGES$. The folder will not be shared after you move or rename it. Are you sure you want to continue?

go ahead and make sure to click on either the "Continue" or "Yes" button.

13. On the server where WDS and the PXE Service Point were uninstalled, delete the folders BootImages and PXEBootFiles under %systemroot%\Temp (usually C:\Windows\Temp). It may be necessary to take ownership of the folders and their subfolders to successfully delete the folders. In some circumstances, it may be necessary to also navigate down the folder hierarchy and take ownership from the bottom up.

14. Reinstall WDS and the PXE Service Point using the instructions in the section "How To Properly Install and Set Up A New Instance of A PXE Service Point".

Testing The PXE Service Point

Once WDS and the PXE Service Point have been installed and configured, test the PXE Service point to see if it is working. Take the following measures to ensure the best testing environment:

1. To eliminate problems with Unknown Computer Support, advertise the Task Sequence to a collection that has known existing clients. If necessary, use the Computer Association node to manually create a client record. For best results, create the record based on the SMBIOS GUID (System UUID) of the PC and NOT the MAC address.

2. To eliminate certain issues that can occur with mandatory assignments, do not add a mandatory assignment to the advertisement of the Task Sequences. Instead the Task Sequence advertisement should be completely optional.

3. Verify the properties of the advertisement and ensure that under the "General" tab the option "Make this task sequence available to boot media and PXE" is checked.

4. Verify the properties of the Task Sequence and ensure that under the "Advanced" tab the option "Use a boot image:" is checked and that a boot image assigned under this option.

5. Refer to the below two KB articles regarding the SMS PXE Cache:

Client machines may fail to boot into PXE if System Center Configuration Manager Service Pack 2 has been applied
http://support.microsoft.com/kb/2019640

Operating system deployment fails in a System Center Configuration Manager 2007 SP1 environment if you deploy a different operating system to a client within one hour of a previous deployment
http://support.microsoft.com/kb/969113

During testing is suggested to set the value of the CacheExpire key to 60 (60 seconds = 1 minute). This will minimize PXE booting issues being caused by the SMS PXE cache. The default of the CacheExpire key is either 0 or 3600, both which are 3600 seconds (1 hour). After testing is complete, the value of this registry setting will need to be determined based on environmental conditions.

Monitoring And Troubleshooting The PXE Boot

The single greatest troubleshooting tool in figuring out why a PXE boot is not working on a client PC is monitoring the SMSPXE.log. The log should be monitored live with SMS Trace/Trace32.exe while a PXE boot is attempted on the client PC. When monitoring the SMSPXE.log, the log should show in real time exactly what is occurring.

1. While attempting a PXE boot on a client PC, perform a live monitor of the log SMSPXE.log with SMS Trace/Trace32.exe. The SMSPXE.log log can be found under the MP/client logs of the ConfigMgr site server hosting the PXE Service Point. The location of the MP/client log files is usually under one of the following paths:

32bit servers
<drive_where_ConfigMgr_is_installed>\Program Files\SMS_CCM\Log
or
%systemroot%\System32\CCM\Logs (usually C:\Windows\System32\CCM\Logs)

64bit servers
<drive_where_ConfigMgr_is_installed>\Program Files (x86)\SMS\CCM\Log
or
%systemroot%\SysWow64\CCM\Logs (usually C:\Windows\System32\CCM\Logs)

32bit or 64bit servers
<drive_where_ConfigMgr_is_installed>\SMS_CCM\Log

2. Monitoring the SMSPXE.log should show the activity in the log when the actual PXE request is occurring. If no activity is occurring, this is usually indicative of one of the following problems:

  • The WDS service has not started or is not running
  • The PC is on a separate subnet or vlan from the WDS and DHCP servers and IP Helpers have not been properly set up
  • DHCP Options 60, 66, or 67 have been configured

3. Enabling debug logging on the SMSPXE.log could assist in troubleshooting why a PC is not PXE booting by giving additional information about the PXE request.  To enable debug logging on the PXE Service Point server for the SMSPXE.log , modify the following registry key on the server to a string value of "True" (without the quotes):

32bit Windows Server
HKLM\SOFTWARE\Microsoft\CCM\Logging\DebugLogging!Enabled

64bit Windows Server
HKLM\SOFTWARE\Wow6432Node\Microsoft\CCM\Logging\DebugLogging!Enabled

Once the change has been made, restart the server for the changes to take effect.

4. Lines in the SMSPXE.log that show PXE requests that contain all Fs as the MAC address similar to the below line can be ignored:

MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=<SMBIOS_GUID> > Received DHCP Request smspxe
Executing LookupDevice(<SMBIOS_GUID>, FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF) smspxe
CDatabaseProxy :: LookupDevice succeeded: 0 0 0 0 smspxe
MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUI=<SMBIOS_GUID > > Device not found in the database. smspx
MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=<SMBIOS_GUID > New client request. RequestID=<Request_ID>. smspxe

These PXE "requests" are just the server doing a self check on itself to ensure the PXE Service Point is up and responding.

5. The error in the SMSPXE.log:

Failed to read PXE settings.
The system cannot find the file specified. (Error: 80070002; Source: Windows) smspxe

can be ignored and is not relevant. It does not indicate that there are any problems.

6. If the following messages appear at the PXE boot screen:

TFTP Download: smsboot\x86\abortpxe.com
PXE Boot aborted. Booting to next device...

or

TFTP Download: smsboot\x64\abortpxe.com
PXE Boot aborted. Booting to next device...

it is indicative that the PXE Service Point and WDS are installed and configured correctly and working as expected. The above error messages occur when an advertised Task Sequence is not found for the PC that is being PXE booted. The PXE Service Point then responds appropriately and sends a PXE abort.

The problem is usually associated with how the Task Sequence is advertised and targeted to the PC. Usually in these scenarios the following message will show up in the SMSPXE.log for the PXE request:

ProcessDatabaseReply: No Advertisement found in Db for device smspxe

7. The SMSPXEIMAGES$ DP is actually a share pointing to the SMSIMAGES folder within the RemoteInstall folder. ConfigMgr places the Boot Images in this share so that the Boot Images are available to WDS for PXE booting. In total there should only be four folders within the RemoteInstall folder as follows:

SMSBoot
SMSIMAGES
SMSTemp
Stores

If additional folders exist in the RemoteInstall folder, such as:

Boot
Images
Mgmt
Templates
Tmp
WdsClientUnattend

this is an indication that WDS has been manually configured at some point. The best course of action at this point is to reset the installation of WDS by reinstalling the PXE Service Point and WDS as described in the section "Reinstalling WDS And The PXE Service Point".

8. ConfigMgr uses the Boot Images in the RemoteInstall\SMSIMAGES folder to extract Boot Files from the Boot Images. In addition to the Boot Images, these Boot Files are also needed by WDS to successfully complete a PXE boot. These Boot Files are placed in the SMSBoot folder under the RemoteInstall folder. The process of extracting the Boot Files can be seen by monitoring the SMSPXE.log while the WDS service is restarted. If errors appear in the log during this process (besides the error described in Step 5 above), the best course of action is to reinstall the PXE Service Point and WDS as described in the section "Reinstalling WDS And The PXE Service Point".

9. The RemoteInstall\SMSIMAGES folder will contain a subfolder called SMSPKG, which will then contain subfolders for each Boot Image that has been added to the SMSPXEIMAGES$ DP. Each subfolder under the SMSPKG folder will have the name of the Package ID of the Boot Image.

If any subfolder exists under SMSPKG that is not the Package ID of a Boot Image, they should be removed from the SMSPXEIMAGES$ DP via the ConfigMgr 2007 Admin console. Only Boot Images should be added to the SMSPXEIMAGES$ DP. No other type of packages should be added to the SMSPXEIMAGES$ DP. This is especially true with Operating System Image Package or an Operating System Install Package (Windows OS source files). Having an Operating System Image Package or an Operating System Install Package under the SMSPXEIMAGES$ DP will cause issues with WDS.

Instructions on how to remove additional packages from the SMSPXEIMAGES$ DP are provide above in Step 4 under the section "Reinstalling WDS And The PXE Service Point". However make sure not to remove the Boot Images as outlined in the instructions.

10. The RemoteInstall\SMSBoot folder should have three folders listed under it, one for each architecture type - ia64, x64, and x86. The ia64 folder will be empty since ia64 is not an officially supported platform for ConfigMgr 2007 OSD. However, both the x64 and x86 folders should have the following files in them:

abortpxe.com
bootmgfw.efi (x64 only)
bootmgr.exe
pxeboot.com
pxeboot.n12
wdsnbp.com

If the folders are missing, empty, or missing files, then BOTH the x64 and x86 Boot Images may not have been placed in the SMSPXEIMAGES$ DP. If both the x64 and x86 Boot Images have been placed on the SMSPXEIMAGES$ DP and the folders still do not exist, are empty, or are missing files, then there may be another problem occurring. The best course of action is to reinstall the PXE Service Point and WDS as described in the section "Reinstalling WDS And The PXE Service Point".

Frank Rojas | System Center Support Escalation Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Announcement: SMS Scan Tools Are Being Retired

$
0
0

AnnouncementLooks like the Configuration Manager team announced yesterday that On April 12th, 2011, SMS 2.0 will reach the end of its extended support lifecycle and at that time the Security Update Inventory Tool (SUIT) or Extended Security Update Inventory Tool (ESUIT) for SMS 2.0 and SMS 2003 will be retired and will no longer be available for download.  Updated catalogs will not be provided after that date.

You are encouraged to begin planning your upgrade to Configuration Manager 2007 to deploy Software Updates.  For customers remaining on SMS 2003 SP3 the Inventory Tool for Microsoft Updates (ITMU) is also an option.

For all the details see this announcement.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Configuration Manager 2007 state messaging–in depth

$
0
0

NewDocsIntoHeadUnderstanding state messaging in ConfigMgr is important – critical software update data relies on this system – but in v.next of ConfigMgr, understanding state messaging is even more important as more and more components take advantage of it.  That said, lets dig into how the state messaging system works…

[Steverac]

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

How to stage Task Sequence Prestaged Media on a hard drive in Configuration Manager 2007

$
0
0

toolsign

When booting into a PC that has had Task Sequence Prestaged Media staged onto it, the Task Sequence may fail almost immediately with the following error message:

Unable to read task sequence configuration disk. For more information, please contact your system administrator or helpdesk operator.

Usually this error message is associated with no network connectivity in WinPE. Bringing up a command prompt in WinPE and running IPConfig confirms that there is no network connectivity, however NIC drivers have been loaded into the Boot Images. Furthermore, the same Task Sequence and Boot Images work fine when not being used with prestaged media (e.g. via PXE or boot media).

Trying to obtain the wpeinit.log from X:\Windows\System32 while in WinPE from the failed deployment to determine why the NIC drivers are not loading reveals that the log does not exist.

Cause

Instructions on how to create Task Sequence Prestaged Media are listed in the below TechNet documentation:

How to Create Task Sequence Prestaged Media : http://technet.microsoft.com/en-us/library/gg294170.aspx

However, once the prestage media is created there is no further instructions on how to stage the Task Sequence Prestaged Media onto the hard drive.  If the Task Sequence Prestaged Media is not staged correctly to a hard drive on a PC, strange behavior may occur when the Task Sequence is started, including the error described above.

Resolution

There are two ways to properly stage a Task Sequence Prestage Media on a hard drive:

  • Manually
  • Via A Task Sequence

Manually Stage A Task Sequence Prestaged Media On A Hard Drive

The following steps will manually stage the Task Sequence Prestage Media onto the hard drive of a PC. Please note that the below instructions:

1. Copy the Task Sequence Prestage Media WIM file and ImageX.exe to a USB Flash Drive. Make sure that both the Task Sequence Prestage Media WIM file and ImageX.exe are in the same directory. Connect the drive to the PC where the Task Sequence Prestage Media needs to be staged onto.

2. On the PC where the Task Sequence Prestage Media needs to be staged onto the hard drive, boot into WinPE 3.0 or newer. The method by which booting into WinPE (PXE, USB media, CD/DVD media) does not matter.

3. Once in WinPE, at the command prompt, type in:

DiskPart

This should give the "DISKPART>" prompt.

4. At the "DISKPART>" prompt, type in:

List Volume

Determine what the drive letter is assigned to the drive from Step 1.

5. At the "DISKPART>" prompt, type in:

List Disk

Determine what disk number is for the hard drive on the PC (usually 0).

6. At the "DISKPART>" prompt, type in:

Select Disk x

where x is the disk number determine in Step 5. Make sure to pick the appropriate disk number as choosing the incorrect disk number could cause the wrong disk to be wiped, resulting in data loss.

7. At the "DISKPART>" prompt, type in the following commands in the following order:

Clean
Create Partition Primary
Select Partition 1
Format FS=NTFS Quick
Active
Assign

8. At the "DISKPART>" prompt, type in:

List Volume

Determine what drive letter was assigned to the hard drive in Step 7.

9. At the "DISKPART>" prompt, type in:

Exit

This should exit DiskPart and return back to the X: command prompt.

10. At the command prompt, using the drive letter determined in Step 4, switch to the drive from Step 1.

11. At the command prompt, switch to the directory that contains the Task Sequence Prestage Media WIM file and ImageX.exe.

12. At the command prompt, type in the following command to stage the WIM file onto the hard drive:

imagex.exe /apply <wim_name>.wim 1 <drive_letter_of_hard_drive>

where <wim_name> is the name of the Task Sequence Prestage Media WIM file and <drive_letter_of_hard_drive> is the drive letter of the hard drive as determined in Step 8. Do not include the brackets (<>) in the command line. For example, if the Task Sequence Prestage Media WIM file is called "prestage.wim" and the drive letter determined in Step 8 is C:, the command would be:

imagex.exe /apply prestage.wim 1 C:

The amount of time it takes to apply the WIM file to the hard drive can vary and depends on the size of the Task Sequence Prestage Media WIM file. Expect for it to at least take several minutes.

13. Once the WIM file is finished being applied to the hard drive, shutdown the PC by running the following command at the command prompt:

wpeutil shutdown

Once the PC is shutdown, the Task Sequence Prestage Media WIM file has been successfully applied to the hard drive of the PC and is ready for delivery to the OEM. Unless in the testing phase, do NOT turn the PC back on before the necessary materials have been delivered to the OEM.

Notes:

1. In Step 1, ImageX is part of the Windows Automated Installation Kit (WAIK). The WAIK is installed on the ConfigMgr 2007 site server. ImageX can be found under the directory Program Files\Windows AIK\Tools\amd64 or Program Files\Windows AIK\Tools\x86. Make sure to choose the appropriate version based on architecture.

2. In Step 1, a DVD disc or network share can be used instead of a USB Flash drive. If a network share is being used, make sure that the appropriate NIC drivers are loaded into the WinPE being used in Step 2. Additionally, in Step 3, use the "net use" command at the command prompt to connect to the network share.

3. To create a WinPE bootable disk for use in Step 2, use the Windows Automated Installation Kit (WAIK). The following guides step through on how to create a WinPE bootable disk:

Walkthrough: Create a Bootable Windows PE RAM Disk on CD-ROM : http://technet.microsoft.com/en-us/library/dd799303(WS.10).aspx
Walkthrough: Create a Bootable Windows PE RAM Disk on a USB Flash Disk : http://technet.microsoft.com/en-us/library/dd744530(WS.10).aspx

The WAIK should be installed on the ConfigMgr 2007 site server.

As an alternative to manually creating a WinPE boot disk, one of the ConfigMgr 2007 Boot Images can be used to boot into WinPE via any advertised Task Sequence to the PC. Just make sure that in the properties of the Boot Image in the ConfigMgr 2007 Admin Console,  the option "Enable command support (testing only)" is checked under the "Windows PE" tab. Additionally, make sure that the advertisement for the Task Sequence(s) are not set to mandatory. When booting into the Boot Image, when the "Welcome to the Task Sequence Wizard" screen appears, do NOT click on the "Next >" button. Instead, hit F8 to bring up the command prompt, then proceed to Step 3.

4. The drive used to boot into WinPE in Step 2 can be the same drive that hosts the WIM file and ImageX from Step 1.

Stage A Task Sequence Prestaged Media Via A Task Sequence

1. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Operating System Images".

2. Right click on "Operating System Images" and choose "Add Operating System Image".

3. Follow the "Add Operating System Image Wizard" and add the Task Sequence Prestaged Media WIM file as an Operating System Image.

4. Once the Task Sequence Prestaged Media WIM file has been added as an Operating System Image, under the node for the newly added Operating System Image, add it to distribution points (DPs) by right clicking on "Distribution Points" selecting "New Distirbution Points", and follow the "New Distribution Points Wizard".

5. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Task Sequences".

6. Right click on "Task Sequences" and then choose "New" --> "Task Sequence" to open the "New Task Sequence Wizard".

7. In the "Create a New Task Sequence" window, select "Create a new custom task sequence" and then click on the "Next >" button.

8. In the "Task Sequence Information" window:

- In the "Task Sequence name:" text box, give the Task Sequence an appropriate name, such as "Stage Task Sequence Prestaged Media WIM File"

- Next to "Boot image:", click on the "Browse..." button and select an appropriate Boot Image.

9. In the "Summary" window, click on the "Next >" button.

10. In the "Wizard Completed" window, click on the "Close" button.

11. On the right hand pane of the ConfigMgr 2007 Admin Console, right click on the newly created Task Sequence and choose "Edit".

12. Click on the "Add" menu and choose "Disks" --> "Format and Partition Disk".

13. In the "Format and Partition Disk" task, next to "Volume", click on the yellow star button to bring up the "Partition Properties" window.

14. In the "Partition Properties" window:

- Next to the "Partition name:" text box, if desired, give the partition a name such as "OS" or "Windows". (Optional)

- Under the "Partition Options" section, click on the option "Make this the boot partition".

- Under the "Formatting options" section, click on the "Quick format" option.

- Leave all other options at their default, and then click on the "OK" button.

15. Click on the "Add" menu and choose "Images" --> "Apply Data Image".

16. In the "Apply Data Image" task, next to the "Image package:" field, click on the "Browse..." button. Select the Task Sequence Prestaged Media WIM file imported in Step 3 and then click on the "OK" button.

17. Click on the "Add" menu and choose "General" --> "Run Command Line".

18. In the "Run Command Line":

- Next to the "Name:" text box, type in: Shutdown

- Under the "Command Line:" text box, type in: wpeutil shutdown

19. Click on the "OK" or "Apply" button to save the Task Sequence.

20. Using normal procedures for advertising Task Sequences, advertise the Task Sequence created in Steps 6-19 to the PC where Task Sequence Prestaged Media WIM file needs to be staged on.

21. Once the Task Sequence has been advertised, run the Task Sequence on the PC where Task Sequence Prestaged Media WIM file needs to be staged on.

Once the Task Sequence completes on the PC, the PC will shutdown. Once the PC has shutdown, the Task Sequence Prestage Media WIM file has been successfully applied to the hard drive of the PC and is ready for delivery to the OEM. Unless in the testing phase, do NOT turn the PC back on before the necessary materials have been delivered to the OEM.

Hope this helps,

Frank Rojas | System Center Support Escalation Engineer

Wilhelm Kocher | Senior Premier Field Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002


Designating a host that is in workgroup fails with error 2912 in System Center Essentials

$
0
0
toolsignSymptoms

You are using System Center Essentials (SCE) 2010 and you try to designate a host that is in a workgroup and not in a domain.  The result is that it fails with the following error:

Error (2912)
An internal error has occurred trying to contact an agent on the <server-name> server.

Recommended Action
Ensure the agent is installed and running. Ensure the WS-Management service is installed and running, then restart the agent.

Cause

This can occur when the host is not in the domain and instead is in a workgroup, causing the authentication between them to fail.

Note that the SCE console does not support the option of adding a host from perimeter network so you have to manually add the perimeter host using VMM Powershell available on SCE server.

Resolution

You can take the steps below to make this work:

1. Connect to the host computer via RDP, then from Control Panel –> Add/Remove programs, un-install the SCVMM 2008 R2 Agent (If already installed manually).

2. Using the source media for SCE, manually install the SCVMM 2008 R2 Agent from \setup\vmm\amd64\SetupVMM.exe.  Select option to install a Local Agent.

3. In this wizard, select the option “This host is on a perimeter network” and specify a password for the Security file encryption key and do not select to use CA certificate.

4. Select Use Local computer name and click Next and Install.

5. This installs the SCVMM agent on that host.  Note that you have to copy that SecurityFile.txt file from Host server to SCE server.

6. Now on the SCE server, open Start Menu –> Microsoft System Center –> Virtual Machine Manager 2008 R2 –> Windows Power Shell –> Virtual Machine Manager.

7. In the power shell run the commands below to add the host:

    a. >Get-VMMServer -ComputerName "<SCE-server-FQDN>" - (This server connects to a SCE server which is an SCVMM server also).
    b. >$Key = Get-Credential

This prompts for the user name and password.  Specify user name as Administrator and the password as the same one you specified during the manual agent install.

    c. >Add-VMHost "<hostname>" -Description "Perimeter host" -RemoteConnectEnabled $False -PerimeterNetworkHost -SecurityFile "C:\temp\SecurityFile.txt" -EncryptionKey $Key - (Note: The location of security file is any location where you copied file from host to SCE server)

8. Now Host should get added fine.

9. You should eventually see the event below in the VM Manager event log on the SCE Server:

    Log Name:      VM Manager
    Source:        Virtual Machine Manager
    Date:          <date, time>
    Event ID:      1705
    Task Category: None
    Level:         Information
    Keywords:      Classic
    User:          N/A
    Computer:      <SCE-server-name>
    Description:
    Job 2bb6c79f-24de-4a9a-a279-036d72165b2e (Add perimeter network host) completed successfully.

10. Now in the SCE console you will see this computer as a host.

11. In the SCE console, below the All Virtual Machines view, you will now see all VMs hosted by this host.

12. While connecting to it, you may get prompted for credentials.  After supplying the correct user name and password it may show one more prompt saying the certificate is not trusted.

13. From this prompt click on view certificate, go to the details tab, click on copy to file and export the certificate as .cer file.

14. From the SCE server –> MMC console –> Certificate snap-in, import this certificate under Trusted Root Certification Authorities.

15. Now exit and reopen the SCE console.

16. The SCE Console should be now able to see the host, all VMs and connect to all VMs fine.

More Information

“You can designate and configure servers as hosts for virtual machines in Essentials 2010 from the Essentials management server or from the Essentials console. You can also set up and manage the virtual machines on hosts in trusted domains, workgroups, or perimeter networks.”

You can find this in the Technet Library at this URL:  http://technet.microsoft.com/en-us/library/ff603625.aspx

Hope this helps,

Milan Jajal | System Center Support Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

What’s New in the Configuration Manager 2007 R3 Transfer Site Settings Wizard

$
0
0

newThe Configuration Manager 2007 R3 Transfer Site Settings Wizard now has two new options:  Power Management Agent and Enable Active Directory Delta Discovery and Delta Discovery Interval.  Our very own Chaohao Xu dissects each of them here.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

FEP 2010 - Deploying Client KB981889 Ahead of Time with ConfigMgr 2007

$
0
0

InformationForefront Endpoint Protection 2010 (FEP 2010) clients require the Windows Filtering Platform (WFP) rollup package KB981889 on Windows Vista, 2008, 2008 R2, and Windows 7. Installing this package requires a client reboot. I recently worked with a customer who wanted to prepare his environment for FEP 2010 by deploying KB981889 via Configuration Manager 2007 software deployment, so that the reboot could take place during a maintenance window, and his FEP rollout could be staged and monitored during normal business hours after the environment had been prepared. I am going to go over our solution in this article, in case anyone else would like to do something similar.

To continue reading click here.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Solution: The Enable BitLocker task fails to run during a ConfigMgr 2007 Task Sequence

$
0
0

ToolsWhen running a Configuration Manager 2007 Task Sequence that has the "Enable BitLocker" task in it, the task fails to run and BitLocker is not enabled on the PC. Examining the SMSTS.log reveals the following error message:

Start executing the command line: OSDBitLocker.exe /enable  /wait:False /mode:TPM /pwd:AD TSManager
!--------------------------------------------------------------------------------------------! TSManager
Expand a string: FullOS TSManager
Executing command line: OSDBitLocker.exe /enable  /wait:False /mode:TPM /pwd:AD TSManager
==============================[ OSDBitLocker.exe ]============================== OSDBitLocker
Command line: "OSDBitLocker.exe" /enable /wait:False /mode:TPM /pwd:AD OSDBitLocker
Initialized COM OSDBitLocker
Command line for extension .exe is "%1" %* OSDBitLocker
Set command line: "OSDBitLocker.exe" /enable /wait:False /mode:TPM /pwd:AD OSDBitLocker
Target volume not specified, using current OS volume OSDBitLocker
Current OS volume is 'C:' OSDBitLocker
FALSE, HRESULT=80004005 (e:\nts_sms_fre\sms\framework\tscore\encryptablevolume.cpp,364) OSDBitLocker
Unable to find instance of 'Win32_EncryptableVolume' where 'DriveLetter' = 'C:'. Ensure that BitLocker Drive Protection is available for this device. OSDBitLocker
m_pEncryptableVolume->Initialize( pszVolume ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\bitlocker\bitlocker.cpp,222) OSDBitLocker
pBitLocker->Initialize( argInfo.sTarget ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\bitlocker\main.cpp,637) OSDBitLocker
Process completed with exit code 2147500037 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Enable BitLocker.
Unspecified error (Error: 80004005; Source: Windows) TSManager

Examining the PC reveals that the Trusted Platform Module (TPM) chip on the PC has been activated and initialized in the BIOS.

Cause

This error can happen if the drive where the Windows OS is being installed on has not been partitioned correctly for use with BitLocker. In order for a PC to be able to boot, the boot manager and boot files cannot be encrypted. For this reason, when BitLocker is being used, these files need to reside on a partition that is not encrypted by BitLocker, therefore two partitions need to be created. The first partition, which is usually 100MB - 300MB in size, is not encrypted, and is used as the boot partition that contains the boot manager and boot files. The second partition is encrypted, takes up the remaining disk space on the drive, and contains the Windows OS on it. The order of the partitions does not matter.

When manually installing Windows 7 or Windows Server 2008 R2 from the original installation source, such as DVD media, Windows Setup will automatically partition the drive into two partitions:

1. The first partition will be 100MB in size, is formatted NTFS, will be labeled "System Reserved", and a drive letter will NOT be assigned to it. Not assigning a drive letter to this partition effectively makes the partition hidden, although assigning a drive letter to it, either via Disk Management or DiskPart.exe, causes it to no longer be hidden. This partition will also be the boot partition and will contain the boot manager and boot files.

2. The second partition will take up the remaining disk space on the drive, will be formatted NTFS, will not contain any label, and will be assigned the drive letter C:. This partition is where the Windows OS is installed on to.

One of the reasons the manual installations of Windows 7 and Windows Server 2008 R2 from original installation source files automatically creates two partitions is in preparation for BitLocker use. Creating the two partitions during Windows installation makes enabling BitLocker much easier in the future.

Manual installations of Windows Vista and Windows Server 2008 from original installation source files did not automatically create the required partitions needed by BitLocker. This made enabling BitLocker in Windows Vista or Windows Server 2008 much harder once BitLocker was desired.

When deploying any version of Windows that supports BitLocker, including Windows 7 and Windows Server 2008 R2, via a ConfigMgr 2007 OSD Task Sequence, the Task Sequence will NOT automatically create the required partitions for BitLocker, whether deploying from an Operating System Install Package (original installation source files) or an Operating System Image. If the required partitions are not set up appropriately during the Task Sequence, when the "Enable BitLocker" task is attempted to be used, then the error will occur.

Resolution

To resolve the problem, the drive needs to be partitioned correctly to support BitLocker. This can be done in one of two ways:

1. Erase the existing single partition on the drive and repartition the drive with two partitions. After repartitioning, format the partitions NTFS. The drawback to this method is that all data on the drive is lost during the repartitioning and format of the drive. This is a problem if USMT with local capture or hardlinking is being used. This method can be accomplished in a ConfigMgr 2007 Task Sequence by using the "Format and Partition Disk" task.

2. Shrink the existing single partition on the drive, and then using the newly freed space, create a new second partition. The newly created partition will actually be the second partition on the drive and not the first. As mentioned, partition order is not relevant when using BitLocker. This method does not erase any of the data on the drive and is desirable when using USMT with local capture or hardlinking. The drawback to this method is that it may take longer to set up, and can be problematic if the drive is low on disk space or highly fragmented. This method can be accomplished in a ConfigMgr 2007 Task Sequence by using the ZTIBde.wsf script from MDT integration

Method 1 is recommended in the following scenarios:

  • Refresh with no USMT
  • Refresh with USMT and a State Migration Point (SMP)
  • New Computer
  • Bare Metal

Method 2 must be used in the following scenarios:

  • Refresh with USMT and local capture
  • Refresh with USMT and local capture with hardlinking

Method 2 can actually be used in ANY of the above scenarios and may be desirable in a Task Sequence that handles multiple scenarios. Method 1 CANNOT be used in any of the scenarios listed under Method 2 as doing so would erase the data captured locally by USMT.

To implement the scenarios, follow the below instructions:

Method 1

To use the "Format and Partition Disk" task in a ConfigMgr 2007 Task Sequence to automatically create the required BitLocker partition:

  1. In the ConfigMgr 2007 Admin Console, under the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node, right click on the affected Task Sequence and choose "Edit".
  2. In the left pane of the Task Sequence select the "Format and Partition Disk", "Partition Disk", or "Partition Disk 0" task.
  3. Double click on the first item under "Volume" to bring up the "Partition Properties".
  4. In the "Partition Properties" window:
    • Next to the "Partition name:" text box, enter in:
      System Reserved
      This name can actually be anything desired as long as it abides by Windows naming rules but it should describe the partition as the boot or BitLocker partition/drive.
    • Under "Partition options", make sure that "Partition type: " is set to 'Primary".
    • Under "Partition options", change the option from "Use a percentage of remaining free space" to "Use specific size". Change the value next to "Use specific size" from 1 MB to 300 MB.
    • Under "Partition options", make sure that the option "Make this the boot partition" is selected.
    • Under "Formatting options”, make sure the "File system:" drop down menu is set to "NTFS".
    • Under "Formatting options”, make sure the "Quick Format" option is selected.
    • Under "Advance options" in the field "Variable: " text box, enter in:
      BOOTPART
    • Click on the "OK" button.
  5. Click on the yellow starburst icon to create a second partition.
  6. In the "Partition Properties" window:
    • Next to the "Partition name:" text box, enter in:
      OS
      This name can actually be anything desired as long as it abides by Windows naming rules but it should describe the partition as the Windows OS partition/drive.
    • Under "Partition options", make sure that "Partition type: " is set to 'Primary".
    • Under "Partition options", make sure the option is set to "Use a percentage of remaining free space". Make sure the value is set to 100.
    • Under "Partition options", the option "Make this the boot partition" should be grayed out and not selected.
    • Under "Formatting options”, make sure the "File system:" drop down menu is set to "NTFS".
    • Under "Formatting options”, make sure the "Quick Format" option is selected.
    • Under "Advance options" in the field "Variable: " text box, enter in:
      OSPART
    • Click on the "OK" button.
  7. Click on the "Apply Operating System" or "Apply Operating System Image" task to select it.
  8. In the "Apply Operating System" or "Apply Operating System Image" task:
    • Under the “Select the location where you want to apply this operating system.” option, in the "Destination:" drop-down menu, select "Logical drive letter stored in a variable".
    • Under the "Select the location where you want to apply this operating system." option, in the "Variable name:" field, enter in:
      OSPART
  9. Click on the "OK" or "Apply" button to save the changes to the Task Sequence.

Notes on Method 1:

  1. If the "Format and Partition Disk" task does not exist in the Task Sequence, it needs to be inserted as the first task into the Task Sequence, or if the "Restart in Windows PE" task exists in the Task Sequence, between the "Restart in Windows PE" and the "Apply Operating System" task. The "Format and Partition Disk" task can be added by clicking in the appropriate place in the Task Sequence to add the task, and then selecting "Add" --> "Disks" --> "Format and Partition Disk". Once the task is created, click on the yellow starburst button next to "Volumes: " to create the first partition and then continue on to Step 4.
  2. In Step 4, the partition size is purposely set to 300MB and not 100MB. In manual installations of Windows 7 and Windows Server 2008 R2 from original installation source files, the partition is set to 100MB. However, it is beneficial to make this partition larger in scenarios where either WinRE (Windows Recovery Environment) or WinPE (Windows Preinstallation Environment) need to be installed onto this partition. A 100MB partition is too small for either WinRE or WinPE to be installed onto. Increasing the size of this partition should allow either WinRE or WinPE to be staged onto this partition. WinRE and WinPE are staged onto this partition in the following scenarios:
    • When enabling BitLocker, BitLocker will move WinRE from the directory %SystemDrive%\Recovery on the larger encrypted partition to a directory on the smaller unencrypted partition. If this was not done, WinRE would not be able to be accessed in scenarios where problems arose on the PC. WinRE is used by Windows to help diagnose and correct problems in Windows installations when Windows cannot boot.
    • In future Refresh or reimaging scenarios, WinPE may need to be staged onto the local drive of the PC for a ConfigMgr 2007 Task Sequence to proceed successfully. WinPE needs to be staged on a unencrypted volume for it to successfully boot.
  3. In Step 8, the Windows OS is applied to the larger partition based on a drive letter stored in a variable. The variable was set earlier during the "Format and Partition Disk" task. The option "Next available formatted partition" cannot be used as this would attempt to install Windows onto the first smaller partition instead of the second larger partition. This would ultimately fail because the first smaller partition does not have enough room to install Windows on to. The error "There is not enough space on the disk. (Error: 80070070; Source: Windows)" would be displayed in the SMSTS.log when this failure occurs.
  4. The "Setup Windows and ConfigMgr" task will take care of setting up the appropriate boot manager and boot files on the partition that has been marked as bootable. When Method 1 is used, the boot manager and boot files are installed on the 300MB boot partition by the "Setup Windows and ConfigMgr" task. No additional action needs to take place to properly install the boot manager or boot files.

Method 2

To use the ZTIBde.wsf script in a ConfigMgr 2007 Task Sequence to automatically create the required BitLocker partition:

  1. Make sure that the latest version of MDT has been installed on the site server and integrated into ConfigMgr 2007. Additionally make sure that the MDT Toolkit Files Package has been created in ConfigMgr 2007 and that is has been placed on Distribution Points that will be available to PCs during the Task Sequence.
  2. In the ConfigMgr 2007 Admin Console, under the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node, right click on the affected Task Sequence and choose "Edit".
  3. Click on the task immediately BEFORE the task "Enable BitLocker" task.
  4. If the "Use Toolkit Package" and "Gather" tasks are already in the Task Sequence between the "Setup Windows and ConfigMgr" and "Enable BitLocker" tasks, then skip to Step 9. If they exist elsewhere in the Task Sequence and not specifically between the "Setup Windows and ConfigMgr" and "Enable BitLocker" tasks, then Steps 5-8 must be followed.
  5. Click on "Add" --> "MDT" --> "Use Toolkit Package". This should add a "Use Toolkit Package" task immediately before the "Enable BitLocker" task.
  6. In the "Use Toolkit Package" task, next to "Toolkit package:", click on the "Browse..."button and select the MDT Toolkit Files Package from Step 1.
  7. Make sure that the "Use Toolkit Package" task is selected, and then go to "Add" --> "MDT" --> "Gather". This should add a "Gather" task immediately after the "Use Toolkit Package" task and before the "Enable BitLocker" task.
  8. In the "Gather" task, click on the option "Gather only local data (do no process rules)".
  9. Click on the task immediately BEFORE the "Enable BitLocker" task. If Steps 5-8 were followed, this should be the "Gather" task.
  10. Click on "Add" --> "General" --> "Run Command Line". This should add a "Run Command Line" task immediately before the "Enable BitLocker" task.
  11. In the newly created "Run Command Line" task:
    • In the "Name:" text box, enter:
      Partition Drive For BitLocker
    • In the "Command line:" text box, enter:
      cscript.exe "%DeployRoot%\Scripts\ZTIBde.wsf" /debug:TRUE
  12. Click on the "OK" or "Apply" button to save the Task Sequence.

The ZTIBde.wsf script leaves the newly created 300MB partition visible and assigned with the drive letter S:. If the partition is desired to be hidden, the drive letter needs to unassigned from the partition. To unassigned the drive letter and "hide" the partition via the ConfigMgr 2007 Task Sequence:

 

  1. In the ConfigMgr 2007 Admin Console, navigate to the "Computer Management" --> "Software Distribution" --> "Packages" node.
  2. Under the "Packages" node, locate the the MDT Toolkit Files Package.
  3. Right click on the MDT Toolkit Files Package and choose "Properties".
  4. Click on the "Data Source" tab. Under "Source directory" determine the location of the MDT Toolkit Files Package source files.
  5. Click on the "OK" button to close the MDT Toolkit Files Package properties window.
  6. Open Notepad.exe and paste the following lines of text into Notepad:
    select volume s:
    remove letter=s
  7. Save the file with the name
    hide-partition-s.txt
    in the "Scripts" folder of the MDT Toolkit Files Package source files as determined in Step 4.
  8. Update the Distribution Points that the MDT Toolkit Files Package are on.
  9. In the ConfigMgr 2007 Admin Console, under the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node, right click on the Task Sequence using the ZTIBde.wsf script and choose "Edit".
  10. Click on the "Enable BitLocker" task to select it.
  11. Click on "Add" --> "General" --> "Run Command Line". This should add a "Run Command Line" task immediately after the "Enable BitLocker" task.
  12. In the newly created "Run Command Line" task:
    • In the "Name:" text box, enter:
      Hide S: Drive
    • In the "Command line:" text box, enter:
      diskpart.exe /s "%DeployRoot%\Scripts\hide-partition-s.txt"
  13. Click on the "OK" or "Apply" button to save the Task Sequence.

Notes on Method 2:

  1. The ZTIBde.wsf script from MDT integration creates the partition without formatting or erasing any data currently on the drive. It does this by using DiskPart.exe to shrink the existing single partition by 300MB, and then using the newly freed up 300MB of space, it creates a new 300MB partition. Unlike in Method 1, the new partition will be the second partition on the drive, not the first. This should not cause any issues.
  2. The ZTIBde.wsf script along with the "Enable BitLocker" task takes care of removing the bootable option from the original partition and marking the newly created partition as the new bootable partition. The tasks also takes care of moving the boot manager and boot files from the original partition to the new partition.
  3. The ZTIBde.wsf script has the added benefit that it will detect if the required BitLocker partition has already been created. If it has it will not take any further action. This is useful in Refresh scenarios where the BitLocker partition already existed from a previous deployment and does not need to be created again.
  4. There is a known problem in the ZTIBde.wsf script of MDT 2010 that prevents it from working properly in x64 OSes. This problem does not exist in the ZTIBde.wsf script in MDT 2008, MDT 2008 Update 1, and has been fixed in MDT 2010 Update 1.  For detailed information, see KB2254610, "ConfigMgr 2007: The ZTIBde.wsf script from MDT 2010 does not work in x64 Windows OSes"
  5. After the "Enable BitLocker" step has run and BitLocker has been enabled, the status of the encryption process can be checked by running the following command at an elevated command prompt after the Task Sequence has completed:

    Manage-bde –status <Drive_Letter>

    where <Drive_Letter> is the drive letter of the disk where BitLocker was enabled (without the brackets <>). For example, to check the encryption method and cipher strength on the C: drive, run the command:

    Manage-bde –status c:

Hope this helps,

Frank Rojas | System Center Support Escalation Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Hardware Inventory in Configuration Manager 2007 fails and the SMSexec.exe process shows high sustained CPU utilization

$
0
0

KBJust a heads up on a new ConfigMgr 2007 Knowledge Base article we published today where Hardware Inventory fails and SMSexec.exe has high CPU utilization :

=====

Symptom

When using system Center Configuration Manager 2007, processing of Hardware Inventory .MIF files fails and the SMSexec.exe process will show high sustained CPU utilization. Also, MIF files will backlog in the following folder:
inboxes\auth\dataldr.box\process

The NextGroupKey value in the ArchitectureMap table will be unusually high (> 20,000).
Note: The following query can be used to examine the value of the NextGroupKey:
select NextGroupKey from ArchitectureMap where ArchitectureKey = 5  
If SQLTracing is enabled on the site server, you will see the following messages repeated:
SQL>>> select NextGroupKey from ArchitectureMap where ArchitectureKey = 5  
SQL>>>>> Done.
SQL>>> update ArchitectureMap set NextGroupKey = NextGroupKey + 1  where ArchitectureKey = 5 and NextGroupKey = 15080
SQL>>>>> Done. 
You can enable SQL tracing by setting the following value: 
On 64-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\Tracing\SQLEnabled = 1
On 32-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SQLEnabled = 1
For more information on SQL Tracing see the following Knowledge Base article:
KB176517 - SMS: Troubleshooting inventory MIF backlog problems (http://support.microsoft.com/kb/176517).

 

Cause

This can occur if the global 'No count' option is enabled on the SQL server hosting the SMS database. If this is enabled, Configuration Manager 2007 cannot get the correct rowcount value from SQL and thus it cannot complete the cycle to extend the schema.

 

Resolution

Disable 'No count' and processing will continue normally. The "No count" option can be found in the SQL Management Studio:  Properties of the SQL Server -> Connections -> 'no count'.  It should be unchecked.

 

More Information

The "No count" option is not enabled by default. Microsoft has not tested Configuration Manager 2007 with the SQL "no count" global option enabled and using this option is not supported. Regardless, you should determine whether other applications that are using the same SQL server require the "No count" setting to be enabled before disabling it.

=====

For the latest version of this article see the link below:

KB2488396 - Hardware Inventory in Configuration Manager 2007 fails and the SMSexec.exe process shows high sustained CPU utilization

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

clip_image001 clip_image002

System Center Configuration Manager 2007 Service Pack 1 has reached the end of its service pack support date

$
0
0

AnnouncementHi All,

I just wanted to send a quick reminder that System Center Configuration Manager 2007 Service Pack 1 has reached the end of its service pack support date:

http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&qid=null&alpha=System+Center+Configuration+Manager+2007&Filter=FilterNO

clip_image002

Note that per the Lifecycle Policy:

The Microsoft Support Lifecycle policy requires that the product’s supported service pack be installed to continue to receive support (including security updates).

Note new Service Pack Lifecycle Support Policy effective April 13, 2010: http://support.microsoft.com/gp/newSPlifecycle

Service Pack Support Policy

  • When a new service pack is released, Microsoft will provide either 12 or 24 months of support for the previous service pack
  • Support for the previous service packs is either 12 or 24 months, varying according to the product family (for example, Windows, Office, Servers, or Developer tools)
  • Support timelines for service packs will remain consistent within the product family
  • Microsoft will publish specific support timelines for a previous service pack when the new service pack is released
  • When support for a service pack ends, Microsoft will no longer provide new security updates, hotfixes or other updates for that service pack. Limited break/fix troubleshooting will continue to be available, as described below.
  • When support for a product ends, support of the service packs for that product will also end. The product’s support lifecycle supersedes the service pack support policy

Customers are highly encouraged to stay on a supported service pack to ensure they are on the latest and most secure version of their product. For customers on unsupported service pack versions, Microsoft offers limited troubleshooting support as follows:

  1. Limited break/fix support incidents will be provided through Microsoft Customer Service and Support; and through Microsoft’s managed support offerings (such as Premier Support).
  2. There will be no option to engage Microsoft’s product development resources, and technical workarounds may be limited or not possible.
  3. If the support incident requires escalation to development for further guidance, requires a hotfix, or requires a security update, customers will be asked to upgrade to a supported service pack.

Have a great week!

Erin Williams | Product Quality Program Manager

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

The Configuration Manager 2007 Reporting Services point fails with 'SRS root folder "configmgr_" is not present'

$
0
0

KBJust a heads up on a new ConfigMgr 2007 Knowledge Base article we published today where a Reporting point fails with 'SRS root folder "configmgr_<sitecode>" is not present':

=====

Symptoms

The Microsoft System Center Configuration Manager 2007 Reporting Services point (ConfigMgr 2007 SRS) may report the following errors in the SMS_SRS_REPORTING_POINT Component Status Log:

SMS_SRS_REPORTING_POINT 7404 SRS is not installed or properly configured on SRS Reporting point server "<servername>".

Cause

This error can occur if the Copy Reports to Reporting Services Wizard has not been run on the server.  This is a manual step that must be completed to create the default reporting structure that the component expects.  This error will be logged every time the Reporting Services SMS_SRS_REPORTING_POINT thread restarts.

Resolution

To correct this error use the following steps:

1. Run the Configuration Manager 2007 Administration Console as an administrator and navigate to Site Database\Computer Management\Reporting\Reporting Services\<SERVERNAME> (where <SERVERNAME is the name of your Reporting Services server).

2. Right-click on Reporting Services and choose Copy Reports to Reporting Services

3. Follow the wizard, using the appropriate choices as outlined in http://technet.microsoft.com/en-us/library/cc161781.aspx

4. Restart the SMS_SRS_REPORTING_POINT thread in ConfigMgr Service Manager.

=====

For the latest version of this article see the link below:

KB2498344 - The Configuration Manager 2007 Reporting Services point fails with 'SRS root folder "configmgr_<sitecode>" is not present'

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

clip_image001 clip_image002


FYI: Integration of TechNet Blog User Account with TechNet Forums Profile

$
0
0

InformationFor those of you who sign-in to comment on the TechNet Blogs, there is a change coming on January 27th 1:00 pm (PST) regarding user accounts and profiles. Please click here to read about this change.

If you have questions please leave a comment on the linked blog post so that the TechNet Blogs platform team can reply to you directly.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Configuring Configuration Manager 2007 Sites for Best Performance

$
0
0

imageWe always seem to get a lot of questions regarding how to configure Configuration Manager 2007 for the best performance and while we've had this information published in TechNet for a while I thought it would be worth a mention here.  Whether you're setting up ConfigMgr 2007 for the first time or you have an implementation that's been up and running for years, you'll probably find something valuable here:

=====

The topics in this section provide performance recommendations that are the result of testing scenarios based on data processing for a central site, with the maximum number of 200,000 supported clients in a Configuration Manager hierarchy, and 2 child primary sites, with the maximum number of 100,000 supported assigned clients each in a Configuration Manager site.

For more information about capacity planning for Configuration Manager site systems, see Configuration Manager Site Capacity Planning.

noteNote : This is not a complete listing of every feature and function implemented during performance testing but rather an example of general performance testing objectives. For more information about common Configuration Manager 2007 performance related questions and sample configurations, see the technical whitepaper at http://go.microsoft.com/fwlink/?LinkID=113136. 

  • Assigned clients were divided between 2 child primary sites with each supporting 100,000 assigned clients.
  • 200 boundaries were defined to manage client site assignment.
  • Computer collections for these sites were created ranging from 1,000 clients to 200,000 clients.
  • Client hardware inventory, including asset intelligence data, was collected (for both full and delta inventory report information).
  • Client software inventory was collected (both for full and delta inventory report information).
  • Active Directory discovery methods were used both for computers and for users.
  • The heartbeat discovery method was enabled.
  • Software distribution performance was tested using 100 distribution points with software distribution advertisements targeting 2,000, 60,000, and 200,000 clients.
  • Software metering was implemented using 1,000 software metering rules.

Before performance testing began, to obtain realistic performance metrics, the Configuration Manager site database was populated with a representative set of Configuration Manager objects.

For each primary site, supporting 100,000 clients, the database size was approximately 40 GB after the initial Configuration Manager object data was imported into the site database.

To continue reading see Configuring Configuration Manager Sites for Best Performance.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Known Issue: Install Software Updates Action Hangs on Windows 7

$
0
0

WarningThe Configuration Manager Sustained Engineering and Customer Support and Services teams are investigating an issue where the Install Software Updates action will hang indefinitely on Windows 7 clients.

When this happens, the task sequence Installation Progress dialog displays "Downloading 1 of x Updates (0% complete) ..." with no change in the progress bar.

If you look at the smsts.log file during this time, you'll see the following entries and the last entry repeats:

//
Installing all updates targetted for this computer
Installation of updates started
Waiting for installation job to complete
Waiting for job status notification ...
Waiting for job status notification ...
Waiting for job status notification ...
//

In addition, the other log files that are associated with the Install Software Updates task (CAS.log, UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log) do not update during this time.

For more details and the latest status ofthis issue please see the following:

Known Issue: Install Software Updates Action Hangs on Windows 7 : http://blogs.technet.com/b/configmgrteam/archive/2011/01/28/known-issue-install-software-updates-action-hangs-on-windows-7.aspx

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Using Configuration Manager 2007 to change the color depth to 8 bpp does not work on Windows 7 clients

$
0
0

KBJust a heads up on a new ConfigMgr 2007 Knowledge Base article we published today where using Configuration Manager 2007 to change the color depth to 8 bpp does not work on your Windows 7 clients:

=====

Summary

When you set the "Color Depth" to 8 bpp for a Windows 7 client using the Configuration Manager Remote Control tool, nothing changes on the client side.

This occurs because Windows 7 no longer supports 8-bit color depth. Configuration Manager 2007 calls the API IRDPSRAPISharingSession::put_ColorDepth to set color depth. In Windows 7, calling put_ColorDepth at 8 bpp would return success but 16 bpp would be applied.

More Information

You can adjust the color depth used to display a client computer desktop by using the Color Depth command from the View menu of the Configuration Manager Remote Control window. If a color depth is selected that is less than the supported color depth of the client computer, the minimum color depth supported by that client will be used instead. For example Windows 7 does not support 8 bpp color depth. If Configuration Manager Remote Control settings for 8 bpp are selected, when connected to a Windows 7 client the color depth setting will remain set to 8 bpp however the display will be 16 bpp as this is the lowest color depth supported by Windows 7.

=====

For the latest version of this article see the link below:

KB2499059 - Using Configuration Manager 2007 to change the color depth to 8 bpp does not work on Windows 7 clients

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

clip_image001 clip_image002

Information on error codes in Configuration Manager 2007

$
0
0

Toolbox3Being on the support side of the business, we often get a variety of questions concerning various error codes and what they mean.  After all, these codes can be invaluable when troubleshooting an issue because with a little research they'll often tell you exactly what's wrong.

So first off, how do you get the error code descriptions in System Center Configuration Manager 2007 reports?  That's an easy one as we already have a Knowledge Base article that tells you exactly what to do:

KB944375 - How to obtain error code descriptions in System Center Configuration Manager 2007 reports

If you just see an error code in the description of the error then this would be a good place to start:

Custom Error Codes for Configuration Manager 2007 : http://technet.microsoft.com/en-us/library/bb632794.aspx

These two resources are invaluable when it comes to troubleshooting an issue so if you haven't already, you'll want to go ahead and book mark these now.  They're an integral part of any ConfigMgr admin's toolbox.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Viewing all 715 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>