June 2009 - Posts
http://blogs.technet.com/mniehaus/archive/2009/05/15/manipulating-the-microsoft-deployment-toolkit-database-using-powershell.aspx
Great post from Michael over on his blog……
See his post for the complete info…
“A couple of weeks ago at the Microsoft Management Summit conference in Las Vegas, I demonstrated some PowerShell scripts for doing a variety of things. I had promised to post those to my blog so that you could use them as well. This is the first of those scripts, designed to help maintain the contents of the MDT database. I have done some additional work on this one since I demonstrated it, and it’s now ready for your enjoyment.
This PowerShell script leverages the PowerShell 2.0 “advanced function” capabilities to write PowerShell cmdlets using PowerShell scripts – no compiled code is required. That does mean that you must be running PowerShell 2.0 CTP3 or later (e.g. the version of PowerShell included in Windows 7). There is no dependency on a particular version of MDT, so you can use this with MDT 2008, MDT 2010, or even BDD 2007 if you so choose.
The script files themselves are rather bare – lots of scripts, very few comments, and no documentation at all beyond what is in this blog post. There just aren’t enough hours in the day to do those types of things. It’s bad enough that the PowerShell module script has already grown to over 1,500 lines.”
I know of two ways to view package dependencies.
One way is use a sql query as per John Nelsons’ blog:
http://myitforum.com/cs2/blogs/jnelson/archive/2008/06/19/118724.aspx
You can take this query and create a web repot from it.
Another way is to use the SMS Package Dependency Viewer:
http://sourceforge.net/projects/smsdepview/
Here is the main program screen:
Here is a sample screenshot of some returned results:
Hope this helps,
Chris
Ping from Jeff Gilbert’s Blog here:
http://myitforum.com/cs2/blogs/jgilbert/archive/2008/10/18/client-is-installed-flag-explained.aspx
Here is the content from Jeff’s posting….
===============================================================
Every now and then you might see someone asking about an SMS or ConfigMgr client being physically installed at the client computer, but not appearing as installed in the admin console. This invariably results in someone else pointing them to their site maintenance tasks configuration—which is generally the culprit. I was doing some things in my lab today so I figured that I'd post a basic description of the behavior.
When a client is installed, the site database is updated with the new client's information. This update also 'sets the client is installed flag' as you see mentioned a lot. What that means is that Client=1 is set in the database for the system. Client=1 means the client is installed and Client=0 means that the client is not installed (you can see this property when viewing a discovered resource's properties by double-clicking the record in the admin console).
Even if you manually uninstall the client software from a computer, the installed flag for the computer is not updated in the site database. When that happens, even though the client is not installed, the site database thinks it is (Client bit still says 1). That's why you might sometimes see clients as installed in the console when you know that the client really isn't installed. This can lead you on all sorts of goose chases trying to troubleshoot client health issues that don't really exist. To ensure that doesn't happen, you need to enable the Clear Install Flag site maintenance task. When that task runs, it looks for client systems that have not talked to the site (sent discovery information) during the client rediscovery period that you've set for the task. By default when the task is enabled, the installed flag is cleared for clients (sets Client=0) that haven't sent in discovery data in over 21 days.
Of course, enabling the Clear Install Flag task can also cause problems of its own. Enabling this task sometimes causes clients that you know are installed, to be displayed as not installed in the console. In other words, the client is installed, but the database has Client=0 for the resource. In the console, these computers show up as installed No, but Approved Yes? If the hardware inventory client agent has been enabled for the site, then checking Resource Explorer for one of these computers also shows that they've sent in hardware inventory reports recently (ConfigMgr clients do not generate DDRs when hardware inventory runs). So now you see a computer resource that says it's not installed, is approved, and has sent in recent hardware inventory information. This can lead to understandable confusion and therein lies the motivation for me to write this post—this scenario occurs if the Clear Install Flag maintenance task has been enabled, but the Heartbeat Discovery method has not been enabled for the site or it has been configured incorrectly.
So, pretending that I haven't already given away the cause, some plausible actions you might take to correct this situation would be to push the client bits out to the system using the client push installation wizard and selecting the option to always install or repair to reinstall the client. This will work initially because once installed, the client will send in a DDR to tell the site that it has happily installed and is functioning. Problem solved you think, but then the next time you look at the client resource, it is back to Client=0. Argh. Continuing with that logic, you might go to that computer, open the client applet and initiate the Discovery Data Collection Cycle, the client will then send in a heartbeat DDR and the resource record is back to Client=1. Great, but eventually the client will be back to Client=0 and you're back where you started from. If your client rediscovery period is set to the default (21 days), then this process could become a lengthy one and affect many clients. Add to the mix that when the site-wide Client Push Installation method is enabled, it will attempt to install the client on any systems assigned to the site that have the Client=0 bit set. If you're in this situation, you might see systems with this issue and then, seemingly at random, it's a whole different set of systems later.
To avoid all of this: If you enable the Clear Install Flag site maintenance task, then make sure that you also enable the Heartbeat Discovery method and schedule the Heartbeat Discovery method's recurrence interval to be shorter than the client rediscovery period for the Clear Install Flag task. This will cause clients to send in heartbeat discovery records to update the database and let the Clear Install Flag task know about their continued existence. If the Clear Install Flag task runs and the site hasn't received a heartbeat DDR from an installed client during the client rediscovery period defined for the task, it will set the client installed bit to 0 and we all know what happens after that occurs.
Bonus tip: Sometimes the name of the Clear Install Flag task throws people, but if you watch the smsdbmon.log (the log file that records scheduled maintenance task actions) then you'll see that in the log this task is called: clear undiscovered clients. So it's probably easiest to think of that task as 'the task that clears the installed flag for clients that haven't been rediscovered'. Add 'by heartbeat discovery' to that mental definition and you're in business.
Hope this helps,
~Jeff
====================================================================
Pulled from Microsoft:
http://support.microsoft.com/kb/867490
By default, client and server component logging is turned on in SMS 2003. However, the log files differ according to the type of client that is installed. For example, the following rules apply:
- The SMS 2003 Legacy Client logs record the same information as the SMS 2.0 client. The Legacy Client log files are located in the %Windir%\MS\SMS\Logs folder on the client computer.
- The SMS 2003 Advanced Client uses different log files than the Legacy Client to record information. The Advanced Client logs are located in one of the following locations:
- On computers that serve as management points, the Advanced Client logs are located in the SMS_CCM\Logs folder.
- On all other computers, the Advanced Client log files are located in the %Windir%\System32\CCM\Logs folder.
Legacy Client log files
The following table describes the Legacy Client log files and lists possible issues that apply.
Log file name
Description
Used to help troubleshoot
APASetup.log
Installation of the Advertised Programs Agent (APA).
Installation of software distribution components.
Ccim32.log
Client Configuration Installation Manager (CCIM). Logs routine verification of client components.
Client installation and upgrade problems.
CliCore.log
Client core components.
Client installation and upgrade problems.
CLISVC.log
Activity of the SMS Client service.
SMS Client service problems.
CQMGR32.log
File copy activity to the client access point (CAP).
Inventory data or status data that is not received by the site.
Hinv32.log
Hardware inventory process.
Hardware inventory problems.
Inhinv32.log
Installation of hardware inventory.
Scenarios where hardware inventory is turned on, but it is not installed on the client.
Insinv32.log
Installation of software inventory.
Scenarios where software inventory is turned on, but it is not installed on the client.
Launch32.log
Records whether users are logged on to the computer.
Scenarios where SMSMON32 does not start, or there are problems with software distribution.
ODPSys32.log
Records the Offer Data Provider (ODP) polling process for advertisements that are based on the computer name.
Scenarios where the client computer does not receive advertisements.
ODPUsr32.log
Records the Offer Data Provider (ODP) polling process for advertisements that are based on the user name.
Scenarios where the user does not receive advertisements.
ODPWnt32.log
Records the Offer Data Provider (ODP) polling process for advertisements that are based on the user group name.
Scenarios where a user group does not receive advertisements.
RemCtrl.log
Installation of the remote control component.
Scenarios where remote control is turned on, but it is not installed on the client.
Sinv32.log
Software inventory process.
Scenarios where software inventory does not run.
SMSAPM32.log
Logs the processing of advertised programs by the Available Programs Manager (APM).
Scenarios where advertisements fail or do not run.
Smscli.log
Logs the start of the Systems Management tool in Control Panel.
Scenarios where the Systems Management tool does not start or does not work correctly.
SMSCLREG.log
Logs registry access when the client is installed.
Client installation issues.
SMSMon32.log
Advertised Programs Monitor log.
Advertisement issues.
SWDist.log
Records the installation of the software distribution components.
Scenarios where software distribution is turned on, but it is not installed.
WNLOGON.log
Logs the client installation process when the logon script is used.
Client installation issues.
WNMANUAL.log
Logs the manual client installation process.
Client installation issues.
WNREMOTE.log
Logs the remote “push” installation of the client software.
Client installation issues.
Advanced Client log files
The following table describes the Advanced Client log files and lists possible issues that apply.
CAS
Content Access service. Maintains the local package cache.
Downloaded package issues and "cache out of space" errors. Make sure package content access is completed.
CcmExec.log
Records activities of the client and the SMS Agent Host service.
Scenarios where the client is corrupted or not functioning. For example, this log applies to a scenario where the client cannot communicate with a management point. Make sure that there are no errors, such as WinHTTP errors, listed.
CertificateMaintenance.log
Maintains certificates for Active Directory directory service and management points.
Scenarios where the client cannot communicate with a management point or with Active Directory.
ClientIDManagerStartup.log
Creates and maintains the client GUID.
Scenarios where the client changes its GUID after a hardware change or after Windows activation.
ClientLocation.log
Site assignment tasks.
Scenarios where the client is not assigned to a site. Make sure that the client has determined its assigned site.
ContentTransferManager.log
Schedules the Background Intelligent Transfer Service (BITS) or the server message block (SMB) to download or to access SMS packages.
Package version issues or packages that are not available.
DataTransferService.log
Records all BITS communication for policy or package access.
Download problems from a management point or a distribution point.
Execmgr.log
Records advertisements that run.
Package errors or packages that are unavailable. Make sure that the program command line has run successfully and that status is generated.
FileBITS.log
Records all SMB package access tasks.
Problems that occur when you run a package from the distribution point when BITS is not turned on.
Fsinvprovider.log (renamed to FileSystemFile.log in all SMS 2003 Service Packs)
Windows Management Instrumentation (WMI) provider for software inventory and file collection.
File system access or the WMI provider.
InventoryAgent.log
This component creates discovery data records (DDRs) and hardware and software inventory records.
Inventory issues or problems where the client cannot access the management point. Make sure that inventory or discovery has finished and that the report is copied to the management point.
LocationServices.log
Finds management points and distribution points.
Name resolution or scenarios where the client cannot find the management point or distribution point in Active Directory or in WINS. Make sure that the client has identified its default management point in WMI. Additionally, make sure that the resident management point or the proxy management point is identified.
Mifprovider.log
The WMI provider for .MIF files.
Scenarios where MIFs are marked "invalid".
Mtrmgr.log
Monitors all software metering processes.
Scenarios where metering cannot monitor a program or add to WMI. Make sure that the software metering rules were downloaded, and that the programs are matched by the rules.
PolicyAgent.log
Requests policies by using the Data Transfer service.
Policy request problems. Make sure that policies were downloaded from the management point.
PolicyAgentProvider.log
Records policy changes.
Policy request problems or WMI errors.
PolicyEvaluator.log
Records new policy settings.
Policy override issues. Make sure that the downloaded policies are applied to the local computer.
Scheduler.log
Records schedule tasks for all client operations.
WMI access errors or scenarios where tasks do not start.
Smscliui.log
Records usage of the Systems Management tool in Control Panel.
The Systems Management tool in Control Panel.
StatusAgent.log
Logs status messages that are created by the client components.
Scenarios where the client cannot send status to the management point.
SWMTRReportGen.log
Generates a usage data report that is collected by the metering agent. (This data is logged in Mtrmgr.log.)
Scenarios where the client cannot send a software metering report to the management point. Make sure that the client can generate a usage report and send it to the management point.
Remctrl.log
Logs when the remote control component (WUSER32) starts.
Scenarios where you try to control the client remotely.
You may see repeated log entries in the SMS 2003 Advanced Client log when the client reports inventory. The log entries indicate any problems that occur when the inventory is reported. For example, you may see the following log entry:
Inventory: Successfully sent report. Destination:mp:MP_SinvEndpoint, ID: {AAEE97B0-271B-42F5-A946-B996592A2539}, Timeout: 10080 minutes
In this example, the destination is defined as a MP_xxxxEndpoint, where xxxx is the SINV component in this example.
Site server log files
The SMS 2003 site server log files are located in the SMS\LOGS folder. Because SMS 2003 relies heavily on Microsoft Internet Information Services (IIS), you can review the IIS log file for additional errors that relate to client access to the IIS server. The IIS log file is located in the %Windir%\System32\logfiles\W3SVC1 folder on the IIS server. The following table describes the site server log files and lists possible issues that apply.
Adminui.log
Records the local SMS Administrator Console tasks when you connect to SMS sites.
Connectivity errors to site servers or to site databases.
Ccm.log
Client Configuration Manager tasks.
Scenarios where the site cannot connect to computers because of permissions or name resolution. Make sure that the site server can connect to the Admin$ share on the client computer.
Cidm.log
Records changes to the client settings by the Client Install Data Manager (CIDM).
Scenarios where the site is not updating CLIDATA.SRC files. Make sure that the correct files are copied to the SMS\Inboxes\Clicomp.src folder.
Colleval.log
Logs when collections are created, changed, and deleted by the Collection Evaluator.
Problems with collections. Make sure that collections are created and updated successfully.
Compsumm.log
Records Component Status Summarizer tasks.
Scenarios that occur when the status system does not update component tallies.
Cscnfsvc.log
Records Courier Sender confirmation service tasks.
Courier Sender errors.
Dataldr.log
Processes Management Information Format (MIF) files and hardware inventory in the SMS database.
Communications errors in the SMS database or "bad" hardware inventory files. Make sure that the delta MIF file was processed to the SMS site database.
Ddm.log
Saves DDR information to the SMS database by the Discovery Data Manager.
Communicating errors with Microsoft SQL Server or "bad" discovery records.
Despool.log
Records incoming site-to-site communication transfers.
Corrupted files or when the Despooler component cannot decompress packages.
Distmgr.log
Records package creation, compression, delta replication, and information updates.
Package source version issues or package update issues.
Hman.log
Records site configuration changes and publishes site information in Active Directory.
Site control serial number or delta serial number issues, or scenarios where the site cannot publish site information to Active Directory. Make sure that *.CT2 files are processed and that child sites attach correctly. Make sure that the site code and roaming boundaries are published to the Active Directory.
Inboxast.log
Records files that are moved from the CAP to the corresponding SMS\INBOXES folder.
Problems with site server permissions or scenarios where the registry is corrupted.
Inboxmgr.log
Records CAP file maintenance.
Problems with permissions or scenarios where the registry is corrupted.
Invproc.log
Records the processing of delta MIF files for the SMS Dataloader component from client inventory files.
Problems with file corruption. Make sure that .nhm files are processed to .mif files.
Mpcontrol.log
Records the registration of the management point with WINS. Records the availability of the management point every ten minutes.
Possible IIS issues if the management point is unavailable. Review this log for other IIS communication issues and WINS registration issues.
Mpfdm.log
Management point component that moves client files to the corresponding SMS\INBOXES folder.
Problems with file permissions.
MPMSI.log
Management point .msi installation log.
Management point installation errors. Search for “return value 3” errors.
MPSetup.log
Records the management point installation wrapper process.
Scenarios where you cannot run Mp.msi or management point installation is not completed. Make sure that Mp.msi was started.
Ntsvrdis.log
SMS server discovery.
Problems with SMS site systems discovery.
Offermgr.log
Records advertisement updates.
File corruption or scenarios where notification and advertisement changes do not occur.
Offersum.log
Records summarization of advertisement status messages.
Status message miscounts or scenarios where summarization files are not created.
Policypv.log
Records updates to the Advanced Client policies to reflect changes to client settings or advertisements.
Scenarios where policy updates do not occur after you make changes to advertisements or to client settings.
Replmgr.log
Records the replication of files between the site server components and the Scheduler component.
A backlog of files in the INBOXES\Schedulr.box\tosend folder or file permission issues. Make sure that outgoing requests are changed to minijobs for the Scheduler component and that incoming files are moved to the correct component.
Rsetup.log
Reporting point setup log.
Installation errors.
Sched.log
Records site-to-site job and package replication.
A backlog of files that are caused by sender errors or by package corruption.
Sender.log
Records files that are sent to other child and parent sites.
Permissions problems for the INBOXES\DESPOOLR.BOX\RECEIVE sending site folder or an incorrect site address. Make sure that the site can connect to the SMS_Site share on the destination site and that data was transferred.
Sinvproc.log
Records client software inventory data processing to the SMS site database in SQL Server.
Problems with corrupted files or access to SQL Server.
Sitecomp.log
Records maintenance of the installed site components.
Upgrade issues, registry or file system permission issues, or scenarios where the site cannot publish site information to Active Directory.
Sitectrl.log
Records site setting changes to the Sitectrl.ct0 file.
Site control file or database corruption. Make sure that the Sitectrl.ct0 file is updated.
Sitestat.log
Records the monitoring process of all site systems.
Scenarios where the site cannot access remote site systems to generate status information for available drive space or available database space.
Smsdbmon.log
Records database changes.
Possible corruption of the registry triggers or a scenario where the site cannot access SQL Server.
Smsexec.log
Records processing of all site server component threads.
Problems with possible site corruption or a scenario where the component services do not start.
Smsprov.log
Records WMI provider access to the SMS database.
Possible WMI corruption or permissions issues with the WMI provider. This file also logs the WMI and SQL queries that are used to access the SMS database.
SMSReportingInstall.log
Records the Reporting Point installation. This component starts the installation tasks and processes configuration changes.
Reporting Point installation.
Srvacct.log
Records the maintenance of accounts when the site uses standard security.
Scenarios where accounts are removed or changed.
Statmgr.log
This component writes all status messages to the database.
Scenarios where status messages do not appear, or they appear corrupted.
Swmproc.log
This component processes metering files and maintains settings.
Scenarios where software metering information does not appear or appears corrupted.
If management points are installed in the site hierarchy, management point log files are stored in the SMS_CCM\LOGS folder on the management point computer. The following table describes the management point log files and lists possible issues that apply.
Collapse this tableExpand this table
Log file name
Description
Used to help troubleshoot
MP_Ddr.log
Records the conversion of XML.ddr records from clients and copies them to the site server.
File corruption or access to the SMS\MP\OUTBOXES\DDR.BOX folder.
MP_GetAuth.log
Records the status of the site management points.
IIS access errors.
MP_GetPolicy.log
Records policy information.
WMI access problems.
MP_Hinv.log
This component converts XML hardware inventory records from clients and copies the files to the site server.
File corruption or access to the SMS\MP\OUTBOXES\HINV.BOX folder. Make sure hardware inventory data is converted from XML to NHM file format.
MP_Location.log
Records location manager tasks.
IIS and WMI access problems.
MP_Policy.log
Records policy communication.
SQL Server access problems.
MP_Relay.log
This component copies files that are collected from the client.
File corruption issues.
MP_Retry.log
Records the hardware inventory retry processes.
Corrupted hardware inventory files.
MP_Sinv.log
This component converts XML hardware inventory records from clients and then copies them to the site server.
File corruption or access to the SMS\MP\OUTBOXES\SINV.BOX folder. Make sure that software inventory data is converted from XML to SIC or SID file format.
MP_Status.log
This component converts XML.svf status message files from clients and copies them to the site server.
File corruption or access to the SMS\MP\OUTBOXES\STAT.BOX folder. Make sure that the status message data is converted from XML to SVF file format.
To turn off logging
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows
You can manually turn on or turn off logging of the SMS components on the SMS 2003 site server. To turn on logging for the site components, follow these steps:
- Click Start, click Run, type regedit, and then click OK.
- Locate the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing subkey.
- Double-click the Enabled value.
- Type 1 in the Value data text box, and then click OK. To turn off logging, use 0 as the Value data. If you want turn off component logging, skip steps 6 and 7.
- Click Start, point to Administrative Tools, and then click Services.
- Stop and then restart the SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services.
The SMS Trace utility
You can use the SMS Trace utility (Trace32.exe) to view the SMS log files in real time. When you use the SMS Trace utility, the log view automatically updates to show new entries. The SMS 2003 SMS Trace utility is included in SMS 2003 Toolkit 1. For more information about SMS 2003 Toolkit 1, visit the following Microsoft Web site:
http://technet.microsoft.com/en-us/sms/bb676787.aspx (http://technet.microsoft.com/en-us/sms/bb676787.aspx)
The SMS 2003 version of the SMS Trace utility includes specific improvements to help you identify error messages and read log files that are generated by IIS.
The SMS 2003 SMS Trace utility has the following feature enhancements:
- You can view IIS, Unicode, and MSI logs.
- You can select errors.
- You can search error codes.
- You can use a new information pane to see additional data that is contained in the log entry.
Another great post from Mr. Niehaus!
http://blogs.technet.com/mniehaus/archive/2008/01/19/microsoft-deployment-configmgr-boot-media-unknown-computers-web-services.aspx
=====================================================================
Did you ever read the title for a blog entry and have no idea what the posting is about? Well, this one might fall into that category. So first, some background information straight from the Microsoft System Center Configuration Manager 2007 documentation (http://technet.microsoft.com/en-us/library/bb633291.aspx):
To deploy an operating system to a new computer without stand-alone media that is not currently managed by Configuration Manager 2007, the new computer must be added to the Configuration Manager 2007 database prior to initiating the operating system deployment process. Although Configuration Manager 2007 can automatically discover computers on your network that have a Windows operating system installed, if the computer has no operating system installed you will need to import the new computer information by using the Import Computer Information Wizard. This wizard supports importing information about a single computer, or importing information about one or more computers from an external .csv file.
Simple enough, but not very convenient: in order to do the import you need to have the MAC address and optionally the SMBIOS UUID of the computer. To get the MAC address of a computer that doesn't yet have an OS, you'd probably need to turn on the computer and go into the BIOS setup, write down the 12-character hex value, then go back to the server and type it in -- accurately.
So ideally we would like to automatically add the computer to the ConfigMgr database just-in-time. Now, there are two scenarios that can be used with ConfigMgr to deploy an OS to a new computer:
- Boot media: inserting a CD or USB key into a computer containing a ConfigMgr-customized version of Windows PE that starts the deployment process.
- PXE boot: network booting a ConfigMgr-customized version of Windows PE that starts the deployment process.
There are different challenges in each of these scenarios, so we'll focus on only the first one for now. When you boot a computer using ConfigMgr boot media, a wizard will start. The first screen don't require that the computer be present in the ConfigMgr database, but in order to complete the wizard it must be. So how can we hook into this wizard to do something about this? That's where the pre-execution hook, described at http://technet.microsoft.com/en-us/library/bb694075.aspx, comes in.
Microsoft Deployment provides a pre-execution hook script that runs a wizard of its own that will call web services to add the computer to the ConfigMgr database, as well as adding the computer to a collection for a task sequence advertisement. After that's complete, then the rest of the ConfigMgr boot media wizard can be completed and the task sequence starts.
So that brings us to the next challenge: setting up the web services. See the documentation at http://technet.microsoft.com/en-us/library/bb978399.aspx for the details, although note that step #2 assumes you are using Windows Server 2008, so the steps are slightly different for Windows Server 2003.
Now, for an experiment. Instead of just trying to explain those steps, I thought it would be useful to record a screencast of the entire configuration process. So you can play the video below for the whole walk-through, which is about 13 minutes long.
Web Service Configuration and Troubleshooting Walkthrough
Assuming you can get this far, everything should be set up properly. (There are some potential additional complications: if you have a larger hierarchy, you may need to verify security to connect to each site, since the computer needs to be present in the ConfigMgr database for the computer's assigned site.) Then you just need to create a new boot image, enabling the pre-execution hook and specifying the URL of the web services. Yes, it's not a trivial setup. And yes, troubleshooting is more difficult than it should be. We'll work on that :-)
Going back to the experiment, if you think screencast recordings like this are useful, please let me know and suggest what additional ones you'd like to see (and hear - adding the audio is the most difficult part).
Published Saturday, January 19, 2008 9:26 AM by mniehaus
In case you haven’t seen this yet, here is the context.
http://blogs.technet.com/msdeployment/archive/2008/01/25/microsoft-deployment-technical-faq.aspx
Microsoft Deployment Technical FAQ
Published 25 January 08 08:10 PM | msdeployment
Microsoft Deployment has been released for a little over three months and we now have had enough questions and support calls come in to generate a FAQ. You might want to bookmark this post because we plan on updating this list as additional questions are asked.
Lite Touch Installation
Q: Is it possible to change the text IT Organization in the task sequence dialog box?
A: Yes! You can set the variable _SMSTSORGNAME in the custom settings.ini to match the text you want to use. For example to set the text to Microsoft Corporation, add the following line to your customsettings.ini:
_SMSTSORGNAME = Microsoft Corporation
Q: What is the purpose of each of the task sequence templates?
A: In BDD 2007 we supported only the installation of a client Operating System and did not technically support using task sequences for anything other than deploying an Operating System. With Microsoft Deployment we now support deploying server Operating Systems as well as running customized task sequences that can perform any number of operations. Here is a list of the templates we provide and their purpose:
- Standard Client Task Sequence - Task sequence used for deploying client Operating Systems such as Windows XP or Windows Vista
- Standard Server Task Sequence - Task sequence used for deploying server Operating Systems such as Windows Server 2003 or Windows Server 2008
- Standard Client Replace Task Sequence - This task sequence is designed to be run on the machine that is being replaced. This task sequence should be initiated within the client Operating System and will perform a User State Migration, Boot into Windows PE, optionally perform a full system backup, and optionally securely wipe the disk
- Custom Task Sequence - This task sequence is used as a template to install Applications. This task sequence can be customized to perform any additional actions that you would like to add
Q: For the Client Replace task sequence, how do I make the task sequence wipe the disk?
A: Set the variable WipeDisk = TRUE in the customsettings.ini
Q: In BDD 2007 I modified ztidiskpart.txt to create partitions. How do I do this in Microsoft Deployment?
A: Microsoft deployment does not use the ztidiskpart.txt file to create the partitions. Now, this disks are configured run time based on the task sequence parameters in the Format and Partition Disk step. This step allows you to create multiple partitions across several disks. If you do not want a partition formatted you can create your own custom script that calls diskpart /s and provide your own diskpart.xt file
Q: When trying to add a custom Vista WIM to the workbench, I receive the following error:
Error during wizard processing
An unexpected error occurred while processing the wizard results.
Collection was modified; enumeration operation may not execute.
A: There is a hotfix available that will fix this problem. See the following KB article for more information and to retrieve the hotfix:
http://support.microsoft.com/kb/941595
Zero Touch Installation with ConfigMgr 2007
Q: How do I use the media hook capabilities in Microsoft Deployment to deploy to unknown computers?
A: Michael Niehaus has a great blog entry and screencast on how to set up and configure this feature: http://blogs.technet.com/mniehaus/archive/2008/01/19/microsoft-deployment-configmgr-boot-media-unknown-computers-web-services.aspx
Q: How do I configure my task sequence to capture a reference image?
A: In the standard client task sequence there are a series of steps at the end of the task sequence that prepare the system for imaging, reboot to Windows PE, and then captures an image of the computer. To enable these steps the following variable should be set in the customsettings.ini, Microsoft Deployment Database, ConfigMgr variables, or task sequence variables:
DoCapture = YES
Q: Do I need to use the Microsoft Deployment database with ConfigMgr 2007?
A: It depends. We have made Microsoft Deployment flexible enough for you to use the Microsoft Deployment Database, customsettings.ini, ConfigMgr 2007 Task Sequence variables, Web Services, or Collection or Computer variables. If you already have a populated database from using BDD 2007, you have the ability to use that database in conjunction with Microsoft Deployment and ConfigMgr by customizing the customsettings.ini to make the database connection. If you choose to use the Microsoft Deployment database (or any other database) then you will need to use the Import Microsoft Deployment Task sequence to create a custom Windows PE image that includes ADO support
Q: What is install updates offline and how do I use it?
A: Install Updates offline is a step that can be added to the task sequence that will install Vista and Windows Server 2008 patches to the Operating System prior to the Operating System booting for the first time. To use this step in the task sequence, you first need to create an updates package inside of ConfigMgr: http://technet.microsoft.com/en-us/library/bb680701.aspx. After creating your updates package you need to add the Install Updates Offline step in the task sequence in the PostInstall section immediately prior to the Configure step
Zero Touch Installation with SMS 2003 OSD
Q: Is it possible to change the text IT Organization in the task sequence dialog box?
A: Yes! Due to how the task sequencing engine works with SMS 2003 OSD, the process is slightly different than for Lite Touch.
Create a variables.dat file in your package source and distribute it to your SMS 2003 Distribution Points. The contents of that variables.dat file should be the following:
<?xml version="1.0"?>
<MediaVarList Version="4.00.5345.0000"><var name=”_SMSTSORGNAME”>My CorpName</var></MediaVarList>
Ok, so there are a number of reasons why you shouldn’t do this, however, it does have it’s purposes as well.
Proceed at your own risk and keep in mind performance might not be the best. I use it for testing mainly. You can use some of the information below to either install a test ESX environment inside VMware workstation on your physical machine, or you can also attempt to install VMware workstation inside a ESX based host.
Getting around Installation errors
So if you try to run either the vmware workstation or vmware server install, you will receive the following error message.
Well i say “boo” to that because i want to test a few things, and sometimes a virtual machine is just an easier/better way to test things.
First we need to extract out our main .exe and create an administrative install we can work with. You can do this using the /a command and then specifying the directory to install:
Once you have your install, you will need to install Orca from the SDK if you don’t already have it, found here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
Once you have Orca installed, you will want to right click on the MSI and click edit with Orca:
Once inside Orca, you will want to browse to the InstallUISequence Table:
Once there, find the VM_CheckVM action:
We want to delete this row:
Then we want to save and exit:
Now the next time you run the setup, you will be able to install either vmware workstation or vmware server on your ESX based virtual machine.
Setting the CPU on the virtual machine
It is recommended that set the CPU on the virtual machine to Intel-VT or AMD-VT
Picking the OS for the virtual machine (creation wizard)
I've seen recommendations for picking Red Hat Linux for your OS in the template, but i haven't verified that is a "must".
Editing .vmx files
Once you have vmware workstation installed, you will have to modify your virtual machine after you create it in order to power on the vm.
Open the new virtual machine's .VMX file in a text editor and make sure the following lines are present for each connected Ethernet adapter. ethernet0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.connectionType = "bridged"
ethernet0.addressType = "generated"
You'll need to add the following lines in the .VMX file in your "host" VM (modify the ESX .vmx if your host is on ESX) and your VMware Workstation .vmx if you are installing ESX inside of VMware workstation:
For Intel-based CPUs:
monitor_control.restrict_backdoor = "TRUE"
monitor_control.vt32 = "TRUE"
If the processor is AMD-based, replace the line monitor_control.vt32 = "TRUE" with monitor_control.enable_svm = "TRUE"
-Chris
Credit to Jake Cohen who suggested this on the MyITForum email list.
Someone asked for a way to restrict people from browsing the default distribution shares and installing whatever they feel like. Below is one method of “locking” down this common share without inhibiting SMS/SCCM software distribution.
We are not going to set or change anything on the default share permissions, default is that Everyone has read/write access, that’s fine, we’ll control it at the NTFS level, since that will apply locally and over the network.
Another thing to note is that this will set the permission on all existing packages, however any newly created packages won’t have these permissions until you re-apply the permissions from the root folder.
First lets go into our share properties:
Next we want to go to the security tab:
Then we want to click on “Add”:
Add “Domain Computers”, click on “Check Names”, then Click on “OK”:
Verify that you have read permissions for Domain Computers (should be selected by default):
Next, we will want to modify the permissions for the server\users group:
Again, we want to uncheck the “List” permissions, then click “OK”:
Next, we want to check the box for “Replace permissions….”, then Click on “OK”
Click “Yes” On this box:
You can verify your permissions for Domain Computers and Users here, then click “OK” when you are done:
Now you have modified the default file security permissions for your package distribution share in SMS/SCCM.
Hope this helps,
-Chris
One method of integrating drivers or mass storage drivers into Windows PE involves using the winpeoem.sif file which is located in the \system32 directory. This will not work with every driver, however, i would recommend trying this method first, since it’s one of the easiest methods to do. If this method doesn’t work, then you may need to modify the txtsetup.sif file.
Here is a picture of the default winpeoem.sif file:
First we will want to create the necessary folder structure for the driver. In this example lets use the VMware SCSI driver.
I’m going to store my drivers under \system32\drivers\VMware_SCSI
So I need to create that folder and then copy my driver files into that folder:
No I also need to look at the txtsetup.oem and see how they want the folder structured.
If you open the txtsetup.oem for the driver you need, you will want to look at the [Disks] section and see what folder it’s expecting to find the driver in.
In this case, denoted by the “\” at the end, it’s expecting all the driver files in the root of the folder. So in this case our “Vmware_SCSI” folder will work just fine.
So we have our files in the correct place, so now we need to somehow let WinPE know that there are some new drivers it can use. We need to modify the winpeoem.sif file.
In the bottom of the file you will find a [OemDriverParams] section.
We need to uncomment this section and add new directory here. The default for the “OemDriverRoot” is “” which means \system32. To keep it cleaner, i created my directory under \system32\drivers, so i need to modify that value to tell it that the “root” directory is now \system32\drivers instead of \system32.
Next we need to modify OemDriverDirs to identify the VMware_SCSI directory we created.
Now, if all goes well, we should have support for the driver we have just integrated, in this case the VMware SCSI driver.
Also here is the explanation of the sections provided by the winpe.chm
