where is bdd.log location?

• BDD.log. This is the aggregated MDT 2010 log file that is copied to a network location at the end of the deployment if you specify the SLShare property in the Customsettings.ini file.

• DeployUpdates_Platform.log. This file is created when deployment shares are updated or when updating Windows Preinstallation Environment (Windows PE). Platform represents the platform being updated—either 32 bit (x86) or 64 bit (x64). This log file is useful when troubleshooting Windows PE driver-integration issues. It resides in the %TEMP% folder.

• LiteTouch.log. This file is created during Lite Touch Installation (LTI) deployments. It resides in %WINDIR%\Temp\BDDLogs unless you specify the /debug:true option.

• Scriptname.log. This file is created by each MDT 2010 script. Scriptname represents the name of the script in question.

• SMSTS.log. This file is created by the Task Sequencer and describes all Task Sequencer transactions. Depending on the deployment scenario, it may reside in %TEMP%, %WINDIR%\System32\ccm\logs, or C:\_SMSTaskSequence, or C:\SMSTSLog.

• To enable monitoring, right-click on the MDT share and click Properties.
• Then go to the Rules 1 tab and in the Default section add the parameter EventService 2 indicating the name of the MDT server and the port (9800), click on Apply 3 and OK 4.

When installing the SCCM2012R2 Toolkit, just select client tools.

Once that’s installed you may need to set CMTrace as your default viewer for logfiles. That’s easy. Open CMTrace once and it’ll ask to be the default. The hard part is knowing which log files to check.

Yes, sometimes knowing if half the battle, and with MDT that battle is knowing where to look for log files. If the imaging hasn’t started and you’re still in WinPE, look in X:\MININT\SMSOSD\OSDLOGS. If the task sequence has started and that PC has at least imaged, look in C:\MININT\SMSOSD\OSDLOGS. If the task sequence has finished, or at least been wrapped up cleanly, look in %WINDIR%\TEMP\DeploymentLogs. MDT will move everything there at the end.

The core MDT log file is BDD.log. MDT will dump that to the Windows temp folder on the system being imaged. If you don’t have server logging set up in your share, set that up. It’ll save you time down the road. It will let you dump logs back to MDT at the end of the deployment. There’s lots of logs for each script that runs as part of the task sequence and you can even specify to log MSI installs during the deployment as well.

Other log files you may want to look for:

Finally, there’s a great guide here that reminds us the most important thing about troubleshooting MDT:

https://docs.microsoft.com/en-us/sccm/mdt/troubleshooting-reference

For more info on Advanced MDT troubleshooting, check out Keith Garner’s guide on TechNet here:

Each script also updates a common master log file (BDD. log) that aggregates the contents of the log files that MDT scripts create. MDT log files reside in C:\MININT\SMSOSD\OSDLOGS during the deployment process.

The deployment of operating systems and applications as well as the migration of user state can be a challenging endeavor, even when you are equipped with appropriate tools and guidance. This reference, which is part of Microsoft® Deployment Toolkit (MDT) 2013, provides information on current known issues, possible workarounds for those issues, and troubleshooting guidance.

Before effective troubleshooting of MDT can begin, you must have a clear understanding of the many .log files used during an operating system deployment. When you know which log files to research for what failure condition and at what time, issues that were once mysterious and difficult to understand may become clear and understandable.

The MDT log file format is designed to be read by CMTrace. Use this tool whenever possible to read the log files, because it makes finding errors much easier.

The rest of this section details the log files created during deployment as well as during Windows Setup. This section also provides examples of when to use the files for troubleshooting.

Each MDT script automatically creates log files when running. The names of these log files match the name of the script—for example, ZTIGather.wsf creates a log file named ZTIGather.log. Each script also updates a common master log file (BDD.log) that aggregates the contents of the log files that MDT scripts create. MDT log files reside in C:\MININT\SMSOSD\OSDLOGS during the deployment process. Depending on the type of deployment being conducted, the log files are moved at the completion of the deployment to either %WINDIR%\SMSOSD or %WINDIR%\TEMP\SMSOSD. For Lite Touch Installation (LTI) deployments, the logs start in C:\MININT\SMSOSD\OSDLogs. They end up in %WINDIR%\TEMP\DeploymentLogs when the task sequence processing is complete.

MDT creates the following log files:

For information about which operating system deployment log files created by Microsoft System Center 2012 R2 Configuration Manager, see Technical Reference for Log Files in Configuration Manager.

When running the Windows User State Migration Tool (USMT), MDT automatically adds the logging options to save the USMT log files to the MDT log file locations. The log files and when they are created are as follows:

If the error count is greater than 0, this event is an Error type. If the warning count is greater than 0 with no errors, then the event is a Warning type. Otherwise, the event is an Informational type.

Table 1 lists the error codes that the MDT scripts create and provides a description of each error code. These error codes are recorded in the BDD.log file.

Listing 1 provides an excerpt from a log file that illustrates how to find the error code. In this excerpt, the error code reported is 5001.

Listing 1. Excerpt from an SMSTS.log file that contains error code 5001

Many error codes presented in the log files seem cryptic and difficult to correlate to an actual error condition. However, the following process demonstrates how to convert an error code and obtain meaningful information that may assist in problem resolution.

Problem: An image capture fails with error code 0x80070040.

Possible Solution 1: The error code presented is in hexadecimal format that you need to convert to decimal format. To do this, you need a scientific calculator, and the calculator included with Windows operating systems is well suited to this task.

To convert an error code

MDT creates log files that you can use to troubleshoot problems in the MDT deployment process. The following sections provide examples of how to use the MDT log files to troubleshoot the deployment process:

Problem: An error occurs while running a deployment that used a CustomSettings.ini file containing numerous sections and specifying, with the Priority property, the priority of each section to be processed. BDD.log contains the following error messages:

Possible Solution: The issue, as pointed out on the first line of the log file sample, is that permission to access the database was denied. Therefore, the script cannot establish a secure connection to the database, possibly because a user ID and password were not available. As a result, database access was attempted using the computer account. The easiest way to work around this issue is to grant everyone Read access to the database.

Prior to embarking on in-depth troubleshooting processes, review the following items and ensure that any associated requirements have been met:

Review the problems and solutions for application installation issues:

Problem: If installation source files are downloaded from the Internet, it is likely that they will be marked with one or more NTFS file system data streams. For more information about NTFS data streams, see File Streams. The existence of NTFS file system data streams might cause an Open File – Security Warning prompt to be displayed. The installation will not proceed until you click Run at the prompt.

Figure 2 shows, you can view NTFS file system data streams using the More command and the Streams utility.

Figure 2. NTFS data streams

Possible Solution 1: Right-click the installation source file, and then click Properties. Click Unblock, and then click OK to remove the NTFS file system data streams from the file. Repeat this process for each installation source file that is blocked by the existence of one or more NTFS file system data streams.

Possible Solution 2: Use the Streams utility, as REF _Ref308173670 \h Figure 2 shows, to remove the NTFS file system data streams from the installation source file. The Streams utility can remove NTFS file system data streams from one or more files or folders at once.

Problem: An installation may fail if it installs device drivers or alters device and network configurations. These changes may result in a lapse in network connectivity that causes the installation to fail.

Possible Solution: Implement the ZTICacheUtil.vbs script to enable download and execution for the installation. This script is designed to tweak the advertisement to enable download and execute. The download uses Background Intelligent Transfer Service (BITS) if the Configuration Manager distribution point is Web-based Distributed Authoring and Versioning and BITS enabled. At the same time, it modifies Configuration Manager to run the ZTICache.vbs script first, which makes sure the program does not delete itself during the deployment process.

Problem: While deploying the 2007 Office system and including a Windows Installer patch (MSP) file, the installation may fail with error code 30029.

Further investigation in the ZTIApplications.log shows the following messages:

Review the problems and solutions for automatic logon issues:

Problem: MDT task sequences are processed during an interactive user session, which requires that the target computer be allowed to log on automatically using a specified administrative account. If a Group Policy object (GPO) is in place that enforces a logon security banner, this automatic logon will not be allowed to proceed, because the security banner halts the logon process while it waits for a user to accept the stated policy.

Possible Solution: Be sure that the GPO is applied to specific organizational units (OUs) and not included in the default domain GPO. When you add computers to the domain, specify that they be added to an OU that is not affected by a GPO that enforces a logon security banner. In the Task Sequence Editor, include as one of the last task sequence steps a script that relocates the computer account to the desired OU.

Problem: You created an image of a computer that was joined to the domain. While deploying the new image to a target computer, the deployment process halts, because auto-logon does not occur and the user is prompted to enter appropriate credentials. The deployment process resumes when the credentials are provided and the user is logged on.

Possible Solution: When capturing images, the source computer should not be joined to a domain. If the computer was joined to a domain, join the computer to a workgroup, re-capture the image, and attempt the deployment to a target computer to determine whether the issue is resolved.

Problem: While deploying to a target computer that is equipped with Intel vPro technology, the deployment may end with a stop error. Even though all updated drivers have been included as out-of-box drivers in the Deployment Workbench, the target computer does not start.

Possible Solution: Review the settings in the target computer's basic input/output system (BIOS) to determine whether the default Serial Advanced Technology Attachment mode is configured as Advanced Host Controller Interface (AHCI). Unfortunately, certain Windows operating systems do not support AHCI by default.

Review database-related problems and solutions:

Problem: During the MDT deployment process, information can be retrieved from Microsoft SQL Server® databases. However, errors might be generated that relate to an improperly configured firewall on the database server.

Possible Solution: The Windows Firewall in Windows Server helps prevent unauthorized access to computer resources. However, if the firewall is configured incorrectly, attempts to connect to a SQL Server instance may be blocked. To access an instance of SQL Server that is behind the firewall, configure the firewall on the computer that is running SQL Server. For more information on configuring firewall ports for SQL Server, see Configure the Windows Firewall to Allow SQL Server Access.

Problem: During the MDT deployment process, information can be retrieved from SQL Server databases. However, errors might be generated that relate to broken SQL Server connections. These can be caused by not enabling named pipe connections in Microsoft SQL Server.

Possible Solution: To resolve these problems, enable named pipes in SQL Server. Also, specify the SQLShare property, which it is required when making a connection to an external database using named pipes. When connecting using named pipes, use integrated security to make the connection to the database. In the case of LTI deployments, the user account that you specify makes the connection to the database. For ZTI deployments that use Configuration Manager, the network access account connects to the database. Because Windows PE has no security context by default, you must make a network connection to the database server to establish a security context for the user who will be making the connection.

The network share that the SQLShare property specifies provides a means to connect to the server to gain a proper security context. You must have Read access to the share. When the connection is made, you can then establish the named pipe connection to the database. The SQLShare property is not needed and should not be used when making a TCP/IP connection to the database.

Enable named pipe connections by performing the following tasks based on the version of SQL Server you are using:

To enable named pipe connections in SQL Server 2008 R2, perform the following steps:

To enable named pipe connections in SQL Server 2005, perform the following steps:

Review MDT-related problems and solutions:

Problem: During the last start-up of a newly deployed computer, the user is prompted to provide user credentials and may receive error 0x80070035, which indicates that the network path was not found.

Possible Solution: Be sure that the WIM file does not include a MININT or _SMSTaskSequence folder. To delete these folders, first use the ImageX utility to mount the WIM file, and then delete the folders.

Problem: If you use the ZTIWindowsUpdate.wsf script to apply software updates during deployment, note that this script may communicate directly with the Microsoft Update website to download and install the required Windows Update Agent binaries, scan for applicable software updates, download the binaries for the applicable software updates, and then install the downloaded binaries. This process requires that your networking infrastructure be configured to allow the target computer to gain access to the Microsoft Update website.

If the deployment share does not contain the Windows Update Agent installation files and the target computer does not have appropriate Internet access, error "wuredist.cab not found" is reported in the ZTIWindowsUpdate.log and BDD.log files.

Possible Solution: Follow the steps outlined in the section, "ZTIWindowsUpdate.wsf", in the MDT document Toolkit Reference.

Review deployment share–related problems and solutions:

In a "simple" environment:

Review Windows Deployment Wizard–related problems and solutions:

Problem: A wizard page is displayed even though the MDT DB or CustomSettings.ini file specify that the wizard should be skipped.

Possible Solution: To properly skip a wizard page, include all properties that would be specified on that wizard page where appropriate in the MDT DB or CustomSettings.ini file along with appropriate values. If a property is configured improperly for a skipped wizard page, that page will be shown. For more information about which properties are required to ensure that a wizard page is skipped, see the section, "Providing Properties for Skipped Deployment Wizard Pages", in the MDT document Toolkit Reference.

Review disk partitioning problems and solutions:

Deploying BitLocker requires a specific configuration for proper deployment. The following potential problems may be related to the configuration of the target computer:

Problem: While trying to deploy BitLocker on the target computer in ZTI or UDI, the ZTIBde.wsf script fails with the error "Unable to open registry key 'HKEY_CURRENT_USER\Control Panel\International\LocaleName' for reading."

Possible Solution: Specify the locale in the UILanguage property. In ZTI and UDI, the ZTIBde.wsf script runs in the system control, so a full user profile is not loaded. When the ZTIBde.wsf script tries to read the locale information it is not in the registry, because the registry (user profile) is not fully loaded. As a workaround, specify the locale in the UILanguage property.

Problem: Some devices can appear as multiple logical drive letters, depending on how they are partitioned. In some cases, they can emulate a 1.44-megabyte (MB) floppy disk drive and a memory storage drive. Therefore, Windows may assign the same device drive letters A and B for floppy disk emulation and F for the memory storage drive. By default, MDT scripts use the lowest drive letter (in this example, A).

Possible Solution: Override the default setting on the Specify the BitLocker recovery details page in the Windows Deployment Wizard. The Windows Deployment Wizard summary page displays a warning to inform the user which drive letter was selected to store BitLocker recovery information. In addition, the BDD.log and ZTIBDE.log files record the removable media devices detected and which device was selected to store the BitLocker recovery information.

Problem: Not enough unallocated disk space exists on the target computer to enable BitLocker. To deploy BitLocker on a target computer, at least 2 gigabytes (GB) of unallocated disk space is required to create the system volume. The system volume is the volume that contains the hardware-specific files needed to load Windows after the BIOS has booted the computer.

Possible Solution 1: On existing computers, use the Diskpart tool to shrink drive C so that the system volume can be created. In some instances, though, the Diskpart tool may not be able to shrink drive C sufficiently to provide 2 GB of unallocated disk space, possibly because of fragmented disk space within drive C.

One possible solution to this problem is to defragment drive C. To do so, perform the following steps:

Problem: When performing a Refresh Computer deployment scenario, the deployment process may fail when deploying to a target computer that is using logical drives or dynamic disks.

Possible Solution: MDT does not support deploying operating systems to logical drives or dynamic disks.

Problem: During deployment, you use the Windows Deployment Wizard to provide all the necessary information for the target computer, including credentials, domain join information, and static IP configuration. When Setup finishes, you can see that the system has not joined the domain and is still in a workgroup.

Possible Solution: An LTI deployment of MDT configures the static IP information after the operating system is up and running. If the target computer is located on a network segment that does not have Dynamic Host Configuration Protocol (DHCP), an automated domain join specified in Unattend.xml will fail when no DHCP is present.

Configure Unattend.xml to join a workgroup. Then, use the built-in Recover from Domain task sequence step to add a step in the task sequence to join the domain after the static IP has been applied.

To ensure the best possible user experience, installation of hardware devices and software drivers should run as seamlessly as possible, with little or no user intervention. Microsoft provides tools and guidelines to help create installation packages that meet this goal. For general information about driver installation, see Device and Driver Installation.

Review device driver installation–related problems and solutions:

The white paper Troubleshooting Device Installation with the SetupAPI Log File provides information about debugging Windows device installation. Specifically, the paper provides guidelines for driver developers and testers to interpret the SetupAPI log file.

One of the most useful log files for debugging purposes is the SetupAPI.log file. This plain-text file maintains the information that SetupAPI records about device installation, service pack installation, and update installation. Specifically, the file maintains a record of device and driver changes as well as major system changes beginning from the most recent Windows installation. This paper focuses on using the SetupAPI log file to troubleshoot device installation; it does not describe the log file sections that are associated with service pack and update installations.

Review the problems and solutions for New Computer deployment scenarios:

In brief, the PXE protocol operates as follows: The client computer initiates the protocol by broadcasting a DHCP Discover packet containing an extension that identifies the request as coming from a client computer that implements the PXE protocol. Assuming that a boot server implementing this extended protocol is available, the boot server sends an offer containing the IP address of the server that will service the client. The client uses Trivial File Transfer Protocol to download the executable file from the boot server. Finally, the client computer runs the downloaded bootstrap program.

The initial phase of this protocol piggybacks on a subset of the DHCP messages to enable the client to discover a boot server (that is, a server that delivers executable files for new computer setup). The client computer may use the opportunity to obtain an IP address (which is the expected behavior) but is not required to do so.

The second phase of this protocol takes place between the client computer and a boot server and uses the DHCP message format as a convenient format for communication. This second phase is otherwise unrelated to the standard DHCP services. The next few pages outline the step-by-step process during PXE client computer initialization.

Review the following solutions for PXE boot issues:

The first procedure recommended is to make sure that logging to setupapi.log has been disabled.

Depending on the router models in use, the specific router configuration of DHCP broadcast forwarding may be supported to either a subnet (or router interface) or a specific host. If the DHCP servers and the computer running Windows Deployment Services are separate computers, ensure that the routers that forward DHCP broadcasts are designed so that both the DHCP and Windows Deployment Services servers receive the client broadcasts; otherwise, the client computer does not receive a reply to its remote boot request.

Is there a router between the client computer and the remote installation server that is not allowing the DHCP-based requests or responses through? When the Windows Deployment Services client computer and the Windows Deployment Services server are on separate subnets, configure the router between the two systems to forward DHCP packets to the Windows Deployment Services server. This arrangement is necessary, because Windows Deployment Services client computers discover a Windows Deployment Services server by using a DHCP broadcast message. Without DHCP forwarding set up on a router, the client computers' DHCP broadcasts do not reach the Windows Deployment Services server. This DHCP forwarding process is sometimes referred to as DHCP Proxy or IP Helper Address in router configuration manuals. Refer to the router instructions for more information about setting up DHCP forwarding on a specific router.

Check the following elements if it is taking a long time (15–20 seconds) for the PXE client computer to retrieve an IP address:

Problem: While testing and troubleshooting a new or modified task sequence, you may need to restart the target computer so that the deployment process can start over from the beginning. Unexpected results may occur, because MDT keeps track of its progress by writing data to the hard disk; any restart of the target computer has MDT resume where it left off at the previous restart.

Possible Solution: To allow the deployment process to restart from the beginning, delete the C:\MININT and C:\_SMSTaskSequence folders prior to restarting the target computer.

Review Sysprep-related problems and solutions:

Problem: The target computer is properly joined to the domain, but the computer account is in the wrong OU.

Possible Solution 1: If an account pre-exists for the target computer, the account will remain in its original OU. To move the account to the specified OU, add a task sequence step that uses an automation tool, such as a Microsoft Visual Basic® Scripting Edition, to move the account.

Possible Solution 2: Verify that the specified OU is in the correct format and that it exists. The correct OU format should be OU=Reception,OU=NYC,DC=Woodgrovebank,DC=com.

Problem: The error message shown in REF _Ref308174600 \h Figure 3 is displayed when you attempt to create a Configuration Manager PXE service point using the Create self-signed PXE certificate option.

Figure SEQ Figure \* ARABIC 3. PXE service point error

Possible Solution: If a PXE service point previously existed on the server you are configuring, the PXE service point may not have deleted the self-created certificates when you uninstalled it. Delete the PXE certificate folder from C:\Documents and Settings\user_name\Application Data\Microsoft\Crypto\RSA, where user_name is the name of the user performing the current configuration or who performed the previous configuration. The New Site Role Wizard in the Configuration Manager console should successfully finish when you have deleted the folder.

Review task sequence–related problems and solutions:

Problem: Task sequence may not finish successfully or has unpredictable behavior.

Possible Solution: The Install Operating System task sequence step (for LTI) or the Apply Operating System Image task sequence step (for UDI and ZTI) may have been modified after the creation of the task sequence step can lead to unpredictable results. For example, if a task sequence was created to deploy a 32-bit Windows 8.1 image, and then later the Install Operating System task sequence step or the Apply Operating System Image task sequence step was changed to reference a 64-bit Windows 8.1 image, the task sequence may not run successfully.

It is recommended that a new task sequence is created to deploy a different operating system image.

Problem: A task sequence based on a LTI OEM task sequence template is showing up for a boot image with a different processor architecture. For example, an OEM task sequence that deploys a 64-bit operation system is showing on a 32-bit boot image.

Possible Solution: This is expected behavior as OEM task sequences in LTI are not considered to be "platform-specific" will always be listed, regardless of the processor architecture of the boot image.

Problem: When running the Windows Deployment Wizard, the wizard displays the error message "Bad Task Sequence Item (Invalid OS GUID)." The operating system is listed in the OperatingSystem.xml file; however, the operating system is not displayed in the Deployment Workbench.

Possible Solution: The original operating system source has two or more WIM files associated. A SKU that is associated with a task sequence is deleted; however, other SKUs for the operating system source still exist. When the task sequence that references the deleted SKU is selected on the Select a task sequence to execute on this computer wizard page in the Windows Deployment Wizard, the error message "Bad Task Sequence Item (Invalid OS GUID)" is displayed after you click Next on the wizard page.

To resolve this problem, perform one of the following tasks:

Problem: When configuring the network connection name in the Deployment Workbench, a validation error prompts you with the message, "Please enter a valid name for the network adapter."

Possible Solution: Remove any spaces and invalid characters from the specified connection name.

If a MDT task sequence is configured not to continue on error and that task sequence returns an error, all remaining task sequences in that task sequence group are skipped. However, the remaining task sequence groups are processed. Consider the following:

Two task sequence groups have been created, and either group contains more than one task sequence step:

Review USMT-related problems and solutions:

Problem: While using USMT to migrate user data, shortcuts that point to network documents may not be restored. The shortcuts are captured during Scanstate; however, they are never restored to the target computer during Loadstate.

Possible Solution: Edit the MigUser.xml file and comment out the following line:

Original:

Modified:

Review WIM-related problems and solutions:

Problem: When deploying an image, the deployment fails with the following entries in the BDD.log file:

Review Windows PE–related problems and solutions:

Problem: When deploying an image to certain target computers, Windows PE starts, runs wpeinit, opens a Command Prompt window but does not actually start the deployment process. Troubleshooting the problem by mapping a network drive from the target computer indicates that the network adapter drivers are not loaded.

Possible Solution 1: The Deployment Wizard is not starting, because there is insufficient RAM. Verify that the target computer has at least 512 MB of RAM and that no shared video memory consumes more than 64 MB of the 512 MB.

The versions of Windows PE that MDT supports are unable to run on a target computer that has less than 512 MB of RAM.

Possible Solution 2: Do not include the wireless drivers in the Windows PE image.

Problem: When troubleshooting a failed deployment, a review of the BDD.log file lists the following entry:

Possible Solution: This error may indicate that the Windows PE image was not created using MDT. If you are using Configuration Manager, do not use one of the existing Windows PE images that Configuration Manager created; instead, create an image using the Import Microsoft Deployment Task Sequence Wizard.

Problem: When deploying to certain target computers, Windows PE starts, runs wpeinit, opens a Command Prompt window, but does not actually start the deployment process. Troubleshooting by mapping a network drive from the target computer indicates that the network adapter drivers are not loaded. A review of the SetupAPI.log file located in X:\Windows\System32\Inf indicates that Windows PE generates errors when it is configuring the network adapter, one of which is, "This driver is not meant for this platform." The drivers in the Out-of-Box Drivers list have been injected into the image.

Possible Solution: It is possible that Windows PE is having a driver conflict with another driver. When configuring the settings for the Windows PE image in the Deployment Workbench, create a Windows PE drivers group that contains only network adapter and storage drivers, and then configure the deployment share to use only the Windows PE driver group.

This section provides two sets of MDT flow charts: one for LTI deployments and one for ZTI deployments with Configuration Manager. Each flow chart illustrates the tasks run during that deployment type.

Familiarize yourself with the deployment process flow charts by:

Flow charts are provided for the following phases:

Flow charts are provided for the following phases of ZTI deployment with Configuration Manager:

At some point you’re going to run into a problem with your imaging process and knowing where to look to get some answers is going to be paramount.

I prefer to keep logs in a central location so they’re easy to find when needed, and for that, we’ll create a new share on our MDT server.  Run the below from the MDT server.

Open your CustomSettings.ini and find a suitable place to add the entries for SLShare and SLShareDynamicLogging depending on your preferred scenario.  Either is fine, just depends on your preference and environment.

Alternatively you could add steps to the Task Sequence itself to set those variables to their appropriate values, be it hard coded or relative.

You can get pretty creative, and for automated deployments, I usually default to something like this:

This way I can see what Task Sequence a particular machine ran. But, to each their own.

Both values do different things:

With the CustomSettings.ini updated, image a machine and check your log directory for a folder structure:

While a machine is imaging, open the BDD.log (in the latter directory mentioned above) with CMTrace from your MDTServer (or whatever machine you’re working on) and you will see live updates:

When the Task Sequence is finished go back into the log directory for that machine and you will to find the logs that were copied up by MDT:

MDT Logs can be a little challenging to locate initially so I recommend you study up those links mentioned in the recommended reading section above.

Keep in mind there are other non-MDT logs you’ll probably need to review that are not listed here.

You now have some historical data to dig into if something goes wrong, which will hopefully be few & far in between!

Good Providence to you!

Applies to: Configuration Manager (current branch)

In Configuration Manager, client and site server components record process information in individual log files. You can use the information in these log files to help you troubleshoot issues that might occur. By default, Configuration Manager enables logging for client and server components.

This article provides general information about the Configuration Manager log files. It includes tools to use, how to configure the logs, and where to find them. For more information on specific log files, see Log files reference.

Most processes in Configuration Manager write operational information to a log file that is dedicated to that process. The log files are identified by .log or .lo_ file extensions. Configuration Manager writes to a .log file until that log reaches its maximum size. When the log is full, the .log file is copied to a file of the same name but with the .lo_ extension, and the process or component continues to write to the .log file. When the .log file again reaches its maximum size, the .lo_ file is overwritten and the process repeats. Some components establish a log file history by appending a date and time stamp to the log file name and by keeping the .log extension.

All Configuration Manager log files are plain text, so you can view them with any text reader like Notepad. The logs use unique formatting that's best viewed with one of the following specialized tools:

To view the logs, use the Configuration Manager log viewer tool CMTrace. It's located in the \SMSSetup\Tools folder of the Configuration Manager source media. The CMTrace tool is added to all boot images that are added to the Software Library. The CMTrace log viewing tool is automatically installed along with the Configuration Manager client. For more information, see CMTrace.

OneTrace is a log viewer with Support Center. It works similarly to CMTrace, with improvements. For more information, see Support Center OneTrace.

Support Center includes a modern log viewer. This tool replaces CMTrace and provides a customizable interface with support for tabs and dockable windows. It has a fast presentation layer, and can load large log files in seconds. For more information, see Support Center Log File Viewer.

You can change the configuration of the log files, such as the verbose level, size, and history. There are several ways to change these settings:

You can also use hardware inventory to collect log settings from clients.

You can set the configuration of the client log files during installation. Use the following properties:

For more information, see Client installation properties.

You can change where Configuration Manager stores the log files, and their size.

To modify the size of log files, change the name and location of the log file, or to force multiple components to write to a single log file, do the following steps:

Use the Windows Registry on the servers or clients to change the following logging options:

When troubleshooting a problem, you can enable verbose logging for Configuration Manager to write additional details in the log files.

After you make changes to these registry settings, restart the component:

The registry settings vary depending upon the component:

To configure logging options for all components on a client or management point site system, configure these REG_DWORD values under the following Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Logging\@Global

For advanced debugging, you can also add this REG_SZ value under the following Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Logging\DebugLogging

This setting causes the client to log low-level information for troubleshooting. Avoid using this setting in production sites. Excessive logging can occur, which might make it difficult to find relevant information in the log files. Make sure to turn off this setting after you resolve the issue.

You can configure settings globally or for a specific component on the Configuration Manager site server.

Configure these values under the following Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing

Only enable SQL Server tracing for troubleshooting purposes. Avoid using it in production sites. Excessive logging can occur, which might make it difficult to find relevant information in the log files. Make sure to turn off this setting after you resolve the issue.

To configure logging options for a specific server component, configure these REG_DWORD values under the following Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\

The DebugLogging setting causes the server to log low-level information for troubleshooting. Avoid using this setting in production sites. Excessive logging can occur, which might make it difficult to find relevant information in the log files. Make sure to turn off this setting after you resolve the issue.

You can configure settings globally or for a specific component on a site system that hosts a Configuration Manager server role.

To configure logging options for a specific server component, configure these REG_DWORD values under the following Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\\Logging

For example, for the distribution point role:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP\Logging

To change the verbose level of the AdminUI.log for the Configuration Manager console, use the following procedure:

Enable or disable verbose logging on a client or collection from the console:

For more information, see Client diagnostics.

Starting in version 2107, you can enable hardware inventory to collect client log file settings. Enable the hardware inventory class, Client Diagnostics (CCM_ClientDiagnostics), and then select the following attributes:

For more information, see Enable or disable existing hardware inventory classes.

Configuration Manager and dependent components store log files in various locations. These locations depend on the process that creates the log file and the configuration of your environment.

The following locations are the defaults. If you customized the installation directories in your environment, the actual paths may vary.

The location of the task sequence log file smsts.log varies depending upon the phase of the task sequence: