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
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.
- Carl
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
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 vulnerabilityWeah passwords checkIIS administrative vulnerabilitySQL 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 AssessmentMBSA 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
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!
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
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.
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