PSS Manageability Official Blog

Stop: 0x0000007B (0xF7CB0524, OxC0000034, 0x00000000, 0x0000000) when using BDD 2007 and XP sp 2 image

pssmanageability — Thu, 08 Feb 2007 18:02:00 GMT

Ran into this problem the other day and came accross this solution. We were using Dell Precision machines (390, 650, and 670) with SATA or SCSI drives This failure occurs while capturing the image after the reboot due to missing mass storage drivers. Here is how to resolve this:

To Install Third-Party Mass Storage Drivers

The following example assumes that you are preinstalling the drivers by using a distribution folder and that you have already created the distribution folder.

1.	If it does not already exist, create an $OEM$ folder under your distribution folder. For example: `X` :\I386\$OEM$
2.	Create a folder named TEXTMODE under the $OEM$ folder. For example: `X` :\I386\$OEM$\TEXTMODE
3.	Copy the third-party mass storage driver files to this folder. These typically include a Txtsetup.oem file and at least one driver file (.sys file), although there may be more. Copy all the files to the TEXTMODE folder.
4.	Use a text editor such as Notepad to edit the `X` :\I386\$OEM$\Textmode\Txtsetup.oem file.
5.	Use the following code to configure your Txtsetup.oem file: [Disks] d1 = "Windows 2003 Driver Set v1.00", w23dsk1, \ Note the backslash character at the end of the second line.
6.	Save the file.
7.	Use a text editor such as Notepad to edit the Unattend.txt file that you are using to perform your unattended installation.
8.	Create the following section: [MassStorageDrivers] " `string that identifies the controller in the [scsi] section of TXTSETUP.OEM` " = "OEM" For example: [MassStorageDrivers] "Adaptec Ultra160 Family PCI SCSI Controller (29160)" = "OEM" Note If you also use this same unattend file on computers that have IDE controllers that start by using the in-box drivers (drivers that are included with Windows), add the following code line to the [MassStorageDrivers] section: "IDE CD-ROM (ATAPI 1.2)/PCI IDE Controller" = "RETAIL" If you do not add this code, you may receive an "Inaccessible Boot Device" Stop error message during the text mode portion of Setup.
9.	In the Unattend.txt file, create an [OEMBootFiles] section and list the files that you previously copied to the Textmode folder. This typically includes an .inf file, a .sys file, and for Windows 2003 a .cat file. For example: [OEMBootFiles] Driver.Sys Driver.INF Driver.CAT Txtsetup.oem
10.	Make sure that OemPreinstall=Yes is in the [Unattended] section of your unattend file. If it is not, Setup does not recognize the drivers.

REFERENCES

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

275334 Error Message: Illegal or Missing File Types Specified in Section Files.SCSI.Name

For additional information about how to configure a Txtsetup.oem file, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/ms794587.aspx

- Carl Sullivan

4918 Errors after applying SMS 2003 SP 2

pssmanageability — Wed, 07 Jun 2006 22:10:00 GMT

You upgrade to SMS 2003 SP2 without extending the schema (remain at SMS SP1 schema) and now you start seeing 4918 errors from the site component manager. SMS will work without the SP 2 schema extension (with no support for FQDN) but it will log many messages like the one in subject.

Is there a way to suppress the generation of these messages while using SMS SP1 schema ?

First option is, tell SMS to not publish to AD. By default it is configured to publish to AD. It’s on the Advanced tab of the Site Properties dialog box. This is not the best option.

Second you could create a status filter rule to filter out this specific error until you can update the schema. This is the better solution and we recommend you upate the schema when possible to obtain this FQDN support.

- Carl

SMS 2003 OS Deployment Feature Pack FAQ

pssmanageability — Fri, 02 Jun 2006 16:34:00 GMT

Does the feature pack support deploying servers?

No. OSD does not officially support deploying servers, it was designed for use with client deployment scenarios. Servers will be fully supported in the next version of SMS.

What is the licensing story for Windows PE?

OSD ships with a version of Windows PE which has been customized for use with the feature pack. This version of Windows PE can only be used with SMS. If you need to create your own version of Windows PE or use it outside of OSD then you must have a Microsoft licensing agreement that allows you to do so.

Does OSD support Windows Vista?

Vista will be supported with an update to the OSD Feature Pack.

Does OSD support 64-bit operating systems?

64-bit operating systems will be supported in the OSD Feature Pack update.

Can I partition disks using OSD?

Yes and no, but mainly no. OSD uses a version of Windows PE that cannot run from RAM. This means that in a normal wipe-and-load scenario that WinPE must run from the local hard disk. This prevents drive partitioning because the disk is locked by the operating system. The exception to this is when deploying a bare-metal machine using a CD or RIS. In this case WinPE is running from the CD or from the network and does not lock the drive, meaning that it could be partitioned. OSD does not provide any built-in partitioning support.

- Carl

Several MP's being refreshed to support SQL 2005 Reporting Services

pssmanageability — Fri, 12 May 2006 17:04:00 GMT

The following existing management packs have been refreshed to support SQL 2005 Reporting Services.

Microsoft Application Center MOM 2005 MP.msi

Microsoft Exchange Server MOM 2005 MP.msi

Microsoft Print Server MOM 2005 MP.msi

Microsoft Virtual Server MOM 2005 MP.msi

Microsoft Web Sites and Services MOM 2005 MP.msi

Microsoft Windows Distributed File Systems MOM 2005 MP.msi

Microsoft Windows Dynamic Host Configuration Protocol MOM 2005 MP.msi

Microsoft Windows File Replication Service MOM 2005 MP.msi

Microsoft Windows Terminal Server MOM 2005 MP.msi

Hope this will help those that have been patiently waiting for these,

Carl Sullivan, Microsoft Manageability

MOM Reporting server hardware replacement

pssmanageability — Wed, 29 Mar 2006 17:38:00 GMT

Question: Is there a procedure to move MOM Reporting server to another server (Hardware replacement and different computer name) ?

The following is a way to do this:

1) If you have any custom reports, export them.
2) Uninstall MOM Reporting. This will not delete the SystemCenterReporting DB.
3) Detach the SystemCenterReporting DB using SQL Enterprise manager.
4) Install MOM Reporting on the new machine.
5) Detach the SystemCenterReporting DB on the new machine, replace the DB file with the old file you detached in step 3. That way you keep your old data.
6) Import the reports for your existing MP's using the MP Import wizard in the MOM Admin Console.
7) Import your custom reports.
8) Setup the SQL Reporting Services permissions to allow users to browse the new reports (like you had before).

Hope you find this useful --- Carl

SMS R2 update

pssmanageability — Fri, 10 Mar 2006 18:08:00 GMT

As of this post the SMS 2003 R2 update is in beta. This update is basically an enhancement to allow SMS administrators the ability to publish software updates for non Microsoft software that may be running in their environment along with the ability to scan their environment for vulnerabilities associated with system configuration. Lets take some time to review both of these additions.

Custom Updates Tool
-----------------------
The Custom Update Tool is a welcome extension to the patch management capability that has been building over time in SMS. Historically patching through SMS has been limited to those patches that are vendor specific - such as Microsoft, Dell and IBM. The custom update tool adds the ability for any vendor to manage software patching through SMS - including any custom applications that may be running in the environment.

The custom update tool is supported on Windows XP SP2 or greater and Windows 2k3 SP1 or greater clients and is driven by a new MMC snapin that allows administrators to import updates from vendors or create updates specific to the environment and publish them all to the SMS server and ultimately the SMS clients for use in scanning and ultimately advertisement targeting. The nuts and bolts of the custom update tool are in many ways very familiar to SMS administrators who are experienced with existing patching - the main difference is the way the patches are imported and/or built in the environment..

Vulnerability Assessment Tool
-------------------------------
SMS has had the ability to detect and deploy missing software updates for some time now. But there are some vulerabilities that expose security risks to organizations that are beyond the scope of what has historically been addressed through software updates. These vulnerabilities fall into the category of systems that may be configured in a way that makes them more subject to a security breach. The vulnerability assessment tool was designed to detect such machines.

The vulnerability assessment tool is based on MBSA technology but is not designed to use any of the patch detection features of MSSA. Instead, MBSA is used to detect common system fulnerabilities that may arise as a result of system configuration that may not be optimal for security. The analysis focuses in several areas:

Windows administrative vulnerability
Weah passwords check
IIS administrative vulnerability
SQL Server administrative vulnerability

SMS administrators familiar with our scanning techologies will be able to use the vulnerability assessment tool very easily. Install is similar to our other scan tools in that the collections, packages and advertisements can be created for you automatically for immediate use. There are two packages created:

Vulnerability Assessment
MBSA 2.0

The Vulnerability Assessment package is runs the vulnerability assessment tool which scans the target computers and reports back vulnerability staus. This is the only package for which an advertisement is created at install. The MBSA 2.0 package is created to allow administrators to distribute MBSA to those computers that don't currently have MBSA installed. Administrators will need to create their own advertisement for the MBSA tool if needed for their environment.

When the vulnerability assessment tool runs it will report back the detected vulnerabilities as hardware inventory - again, just line our other scan tools.

- Steve

Support for SMS 2.0 ending soon

pssmanageability — Tue, 07 Mar 2006 17:44:00 GMT

It's been a good run but all good things come to an end! :)

SMS 2.0 mainstream support will end as of March 2006 so hopefully those still running an SMS 2.0 heirarchy are in full scale upgrade mode moving to SMS 2003!

Understanding SMS Client Side Software Installation Security

pssmanageability — Wed, 22 Feb 2006 23:54:00 GMT

Following is the draft of another article I have written and submitted to technet magazine for publication. This is not yet published so am including the draft here.

Understanding SMS Client Side Software Installation Security

When configuring a software package for distribution in SMS 2003 administrators must choose the user context under which the software will be installed – either the logged on user or administrative context. Choosing “local user” causes the software installation to be executed under the context of the user currently logged onto the computer. Because this option requires a user be logged onto the target computer, and is very limited if the local user does not have administrative rights to the computer, it is more common for software distributions to be sent under administrative credentials.

On an SMS 2003 advanced client, software distributions configured to install using administrative credentials causes the software program to be executed in the context of the local system account On legacy clients, selecting administrative installations causes the software installation to be executed under the context of the SMS Client Token local Account (smsclitoknlocalacct&). This account is created as a typical user account and elevated to have needed administrative credentials at the time of software install. For workstations and member servers, this account is unique to that particular system and is stored in the local SAM database. Domain controllers also use this account but share a domain copy of the account.

The choice to use the local system account for the advanced client allows for increased security and for those familiar with the legacy client or SMS 2.0, requires additional understanding to know what to expect. As an example, consider distribution of an MSI package. If this MSI package has been built to attempt a ‘per user’ install instead of ‘per system’ install – the installation may fail or the results may be unexpected. Commonly, MSI packages can be forced to ‘per computer’ installations by adding the ‘allusers = 2’ switch to the MSI command line through SMS. Consider further software distributions that are initiated from the SMS distribution points but during execution attempt to access network resources external to the SMS distribution point. The SMS advanced client and SMS legacy client handle this situation differently and without good understanding of these differences, software installations may be inconsistent between the two clients. More on this shortly.

When distributing software using administrative credentials, the local system account (advanced client) and SMS Client Token Local Account (legacy client) have full administrative privilege to the local computer but do not necessarily have access to network resources that might be needed during software execution.

When the SMS 2003 advanced client initiates software execution it will connect to the SMS Distribution Point to retrieve the package of interest. Assuming all required software files are available on the SMS distribution point the software installation proceeds. If the software being requested does not reside on an SMS distribution point or if during software installation references are made to a non-SMS share then SMS will attempt to connect to that share location under the context of the Advanced Client Network Access Account. If this account is not configured or does not have rights to the requested share, the software installation will fail and errors will be noted in the execution manager log (execmgr.log). Typically errors in this log will reflect an access denied when the SMS client attempts to access this non-SMS share. It should be noted, however, that even if the network access account is used, the actual installation of the software is still handled by the local system context. The Advanced Client Network Access Account is used strictly for network access.

In contrast to the advanced client, the SMS 2003 legacy client has the ability to use the Software Installation Account. Administrators familiar with an SMS 2.0 environment will also recognize this account. In contrast to the advanced client, when the software installation account is chosen this account is used to access non-SMS shares for software installation – just as the Advanced Client Network Access Account – but is also used to perform the actual software installation. At runtime this account is elevated (if necessary) to have administrative privilege and performs the software installation.

Having a good understanding of how network communication is facilitated for each client during software distribution can help pinpoint failures should they occur. Execmgr logging (advanced client) or SMSAPM32 logging (legacy client) is often useful to track the cause of errors. Knowledge base article 833417 may be helpful for further understanding SMS logging options

-Steve

MOM 2005 solution accelerators overview

pssmanageability — Wed, 22 Feb 2006 23:38:00 GMT

Recently, I published an article in Technet magazine that reviews several of the available solution accelerators for MOM 2005. That article in draft form is attached. Solution accelerators in MOM 2005 offer MOM admins additional support, technology and guidance to help address specific deployment concerns - such as alert tuning, continuity of monitoring service and email notifications.

- Steve

Welcome

pssmanageability — Wed, 22 Feb 2006 23:35:00 GMT

This is the official PSS blog for Microsoft Manageability Support. Topics here will include SMS, MOM and SCRM. The content on this blog will be posted by the various team members of manageability PSS supporting these various technologies. Some of the posts here that are of particular interest may be copied from individual engineers blog sites as well

More to come soon!

PSS Manageability