Google News
logo
SCCM Interview Questions
SCCM (System Center Configuration Manager) is a Microsoft product designed to manage, deploy, and update devices and software throughout an enterprise. Configuration Manager will commonly use SCCM for endpoint protection (manage Windows Firewall settings on client computers), patch management, software distribution, operating system deployment, network access protection, and hardware and software inventory, among other things. It enables users to manage computer systems running Windows, macOS, Linux, and Unix, as well as mobile devices running Windows, iOS, and Android. 
 
* SCCM was originally released in 1994 as SMS (Systems Management Server).

* SMS was renamed to SCCM in November 2007 and is sometimes referred to as ConfigMgr (Configuration Manager).

* In 2020, SCCM was renamed again as Microsoft Endpoint Configuration Manager(MECM). Endpoint Configuration Manager 2111 is the latest version of SCCM
The most important features of SCCM are as follows :
 
* Software deployment and management
* Operating System Deployment
* Patch management
* Desired Configuration Management
* Asset tracking
* Reporting
* Handle computer systems that run either on Windows or Linux, or macOS.
* Remote control etc.
Software Deployment and Management is the ability to deploy software remotely on individual computers, multiple desktops, or even every system on a corporate network. Effective software deployment management allows organizations to seamlessly install or remove software across their corporate devices, enabling employees to do their jobs without interruption and ensuring all corporate devices are in compliance with corporate standards.
 
Software deployment and management tools must allow organizations to effectively manage all endpoints by providing full visibility of software inventory and the versions installed across company devices, no matter the location or the domain.
 
Automated software deployment removes the burden of having to manually update corporate endpoints for larger corporations, reducing the amount of labor and cost necessary to keep corporate devices up-to-date.
When you deploy operating systems, you can save the user state from the destination computer, deploy the operating system, and then restore the user state after the operating systems is deployed. This process is typically used when you install the operating system on a Configuration Manager client computer.
* Configuration Manager provides several methods that you can use to deploy an operating system. There are several actions that you must take regardless of the deployment method that you use:
 
* Identify Windows device drivers that are required to start the boot image or install the operating system image that you have to deploy.
 
* Identify the boot image that you want to use to start the destination computer.
 
* Use a task sequence to capture an image of the operating system that you will deploy. Alternatively, you can use a default operating system image.
 
* Distribute the boot image, operating system image, and any related content to a distribution point.
 
* Create a task sequence with the steps to deploy the boot image and the operating system image.
 
* Deploy the task sequence to a collection of computers.
 
* Monitor the deployment.
There are many Operating System Deployment Scenarios in Configuration Manager that you can choose from depending on your environment and the purpose for the operating system installation. For example, you can partition and format an existing computer with a new version of Windows or upgrade Windows to the latest version. To help you determine the deployment method that meets your needs, review Scenarios to deploy enterprise operating systems. You can choose from the following operating system deployment scenarios:
 
* Upgrade Windows to the latest version
 
* Refresh an existing computer with a new version of Windows
 
* Install a new version of Windows on a new computer (bare metal)
 
* Replace an existing computer and transfer settings
There are several methods that you can use to deploy operating systems to Configuration Manager client computers.
 
PXE initiated deployments : Pre-boot eXecution Environment (PXE)-initiated deployments let client computers request a deployment over the network. In this method of deployment, the operating system image and a Windows PE boot image are sent to a distribution point that is configured to accept PXE boot requests. 
 
Make operating systems available in Software Center : You can deploy an operating system and make it available in the Software Center. Configuration Manager clients can initiate the operating system installation from Software Center. 
 
Multicast deployments : Multicast deployments conserve network bandwidth by concurrently sending data to multiple clients instead of sending a copy of the data to each client over a separate connection. In this method of deployment, the operating system image is sent to a distribution point. This in turn deploys the image when client computers request the deployment. 
 
Bootable media deployments : Bootable media deployments let you deploy the operating system when the destination computer starts. When the destination computer starts, it retrieves the task sequence, the operating system image, and any other required content from the network. Because that content is not included on the media, you can update the content without having to re-create the media.
 
Stand-alone media deployments : Stand-alone media deployments let you deploy operating systems in the following conditions:
 
   * In environments where it is not practical to copy an operating system image or other large packages over the network.
   * In environments without network connectivity or low bandwidth network connectivity.
 
 
Pre-staged media deployments : Pre-staged media deployments let you deploy an operating system to a computer that is not fully provisioned. The pre-staged media is a Windows Imaging Format (WIM) file that can be installed on a bare-metal computer by the manufacturer or at an enterprise staging center that is not connected to the Configuration Manager environment.
 
Later in the Configuration Manager environment, the computer starts by using the boot image provided by the media, and then connects to the site management point for available task sequences that complete the download process. This method of deployment can reduce network traffic because the boot image and operating system image are already on the destination computer. You can specify applications, packages, and driver packages to include in the pre-staged media. 
Desired Configuration Management (DCM) : It is the feature that complies with the IT guidelines laid down by an organization, and the standard configuration of a system cannot be modified/altered. With DCM, you can ensure that your managed systems are compliant with key configuration settings that are important to your organization. It ensures that all systems have the same software setup, drivers, updates, and configuration settings.
The various types of sites available in SCCM are as follows :

* Central Administration site
* Primary site
* Secondary site
CAS (Central Administration Site) : The central administration site is the top-level site in a hierarchy. When you configure a hierarchy that has more than one primary site, install a central administration site. If you immediately need two or more primary sites, install the central administration site first.
 
In CAS, only primary sites are supported as child sites, and a single CAS can support 25 child primary sites so as to extend the scale of your hierarchy. This configuration is necessary because a CAS cannot manage devices directly, which is what primary sites do. CAS is used primarily for reporting and administration purposes.
 
Ex : 
1 CAS =  7 Lakh+ Clients
1 CAS supports how many Primary sites = 25 Primary sites
The site is used to manage devices directly as well as manage bandwidth when your managed devices are distributed across different locations. Almost every client is connected to the primary site. Here, it should be noted that a primary site can only support child secondary sites. Each primary site is capable of supporting up to 250 secondary sites and the hierarchy of more than 100,000 clients.
 
* Primary site can support up to 250 secondary sites (It’s completely depends on WAN speed)

In SCCM 2007 :
Not much difference but in SCCM 2007 Primary can have multiple primary sites.
Use secondary sites to manage the transfer of deployment content and client data across low-bandwidth networks.
 
You manage a secondary site from a central administration site or the secondary site's direct parent primary site. Secondary sites are attached to a primary site. You can't move them to a different parent site without uninstalling them and then reinstalling them as a child site below the new primary site.
 
However, you can route content between two peer secondary sites to help manage the file-based replication of deployment content. To transfer client data to a primary site, the secondary site uses file-based replication. A secondary site also uses database replication to communicate with its parent primary site.
 
Consider installing a secondary site if any of the following conditions apply :
 
        * You don't require a local point of connectivity for an administrative user.
 
        * You're required to manage the transfer of deployment content to sites lower in the hierarchy.
 
        * You're required to manage client information that's sent to sites higher in the hierarchy.

The following information can help you decide when to install a secondary site :
 
        * If a local instance of SQL Server isn't available, secondary site servers automatically install SQL Server Express during site installation.
 
        * Secondary site installation is initiated from the Configuration Manager console, instead of running setup directly on a computer.
 
        * Secondary sites use a subset of the information in the site database. This behavior reduces the amount of data that SQL Server replicates between the parent primary site and secondary site.
 
        * Secondary sites support the routing of file-based content to other secondary sites that have a common parent primary site.
 
        * Secondary site installations automatically install the management point and distribution point site system roles on the secondary site server.
 

* Each secondary site has its own SQL database server (SQL Express) that helps establish the connection between clients and primary site servers.

* Secondary site servers support 5,000 client hierarchies, and they also deploy SCCM clients.
The distribution point helps the client systems obtain the content (files) necessary for installations (Packages, Applications, OS, Driver Packages, etc.)
This can be either a local or remote distribution point. Distribution points can support up to 4,000 clients, and by default, primary sites and secondary sites are also distribution points.

* 1 Distribution Point Supports = 4000 Clients
* 1 Management Point Supports = 25000 Clients
Management Point : It will send and receive the policy to server to client & Client to server
 
Distribution Point : A network location all your software’s are stored.
Primary Site : 
*
The primary site can access with Microsoft SQL Database.
* It can administer through the Configuration Manager console.
* The primary site can be used as a child of another primary site, or it can have its own child sites.
* Clients can assign the sites directly.

Secondary Site : 
*
The secondary can't access to the Microsoft SQL Database.
* It can only administer through the Primary Site.
* In this secondary site, it cannot be used as a child site of its own.
* Clients can't assign the site directly.
Site Database Server : This is a server with Microsoft SQL Server installed, hosting the ConfigMgr site database.
 
Site Server : A site server is a computer system where Configuration Manager 2012 or 2007 is installed. This main role contains components and services required to run a central administration, primary, or secondary site.
 
Site System : This role supports both required and optional site system roles. Any server (or share) with an assigned role automatically receives this role. For Example Similar to a Windows Server role. SUP, DP, MP, Asset Intelligence sync point, etc.
In System Center 2012 Configuration Manager, all collections must be limited to the membership of another collection. When you create a collection, you must specify a limiting collection. A collection is always a subset of its limiting collection.
The Configuration Manager console uses HTTP to the Internet in two scenarios :
 
* When you use the geographical view from the Site Hierarchy node in the Monitoring workspace, which uses Internet Explorer to access Bing Maps.
* When you use the Configuration Manager help file and click a link to view or search for information on TechNet.

If you do not require these functions, your firewall can block HTTP connections from the console without additional loss of functionality to Configuration Manager.
No. The Active Directory schema extensions for System Center 2012 Configuration Manager are unchanged from those used by Configuration Manager 2007.
 
If you extended the schema for Configuration Manager 2007, you do not need to extend the schema again for System Center 2012 Configuration Manager or System Center 2012 Configuration Manager SP1.
In System Center 2012 Configuration Manager, secondary sites require either SQL Server, or SQL Server Express to support database replication with their parent primary site. When you install a secondary site, Setup automatically installs SQL Server Express if a local instance of SQL Server is not already installed.
System Center 2012 Configuration Manager has replaced the native mode site configuration in Configuration Manager 2007 with individual site system role configurations that accept client communication over HTTPS or HTTP.
 
Because you can have site system roles that support HTTPS and HTTP in the same site, you have more flexibility in how you introduce PKI to secure the intranet client endpoints within the hierarchy. Clients over the Internet and mobile devices must use HTTPS connections.
The child site is a site that provides a structure and gets all the data from a Higher level site. 
Background Intelligence Transfer Service (BITS) is used to transfer the data between the SCCM Server and the client. It is even used to download the client to the machine when we start the client push.
SCCM provides several client deployment/installation options, including:   
 
Client push installation : This allows you to automatically install the client software on a computer, or on a group of computers. (90% of Usage)

Manual installation :
This allows you to install the client software manually on computers using CCMSetup.exe. (5% of Usage)

Group policy installation : This allows users to access the client software under Add or Remove Programs in the Control Panel and install it from there. (2% of Usage)

Software update point-based installation : In the case of client software installed on a computer, the computer receives client policies from the site. The policy states the name and port of the software update-point server from which one can obtain software updates. (1% of Usage)

Logon script installation : The login script installation is similar to the manual installation. The /logon installation parameter can be specified for CCMSsetup.exe. Whenever a client version is already installed on a computer, this parameter prevents its installation.(1% of Usage)

Imaging  : Imaging services are provided through System Center Configuration Manager, SCCM. Operating System deployment are done using Task Sequences. You can think of a Task Sequence as a script that SCCM executes from top to bottom. Logic can be added to steps to allow SCCM to make decisions on whether or not certain sections or steps should be executed.(1% of Usage)
Microsoft defines a boundary as a network location on the intranet that can contain multiple devices that you want to manage. Boundary groups are basically the logical groups of boundaries. Any number of boundary groups can be included in a hierarchy. Each boundary group may contain any combination of the following types of boundaries: 

* IP subnet 
* Active Directory site name 
* IPv6 prefix 
* IP address range 
* VPN
When the Configuration Manager client (software) is installed on your Windows devices, you can monitor their health and activity in the Configuration Manager console. Configuration Manager provides different types of information on the client status, such as client checks, client activity, client online status, etc. Generally, a Client check describes the status of the periodic evaluation carried out by the Configuration Manager client on the device. This evaluation can identify some of the problems with the device and remediate them if necessary.
* SMS Providers are essentially WMI (Windows Management Instrumentation) providers that provide read and write access to Configuration Manager databases.

* Configuration Manager administrative users are able to access information stored in a database by using the SMS Provider. It enables access and modifies Configuration Manager data.

* There must be at least one SMS provider per CAS and primary site. More providers can be installed as necessary.

* Secondary sites do not support SMS providers.
The ports mostly used in SCCM are as follows: 
 
* TCP 2701 
* Default HTTPS port 443 
* Client to site system HTTP port 80 
* SMB 445
Windows Server Update Service (WSUS) is used to deploy the existing updates in the product to systems that execute the Windows OS.
Software Update (SUP) is the site system role that is used to create on the server where WSUS has been installed. The SUP and WSUS combine with one another to build the software update backgrounds and demand for Software Updates metadata.
Following are the different discovery methods in SCCM :
 
* Active directory Forest Discovery
* Active directory Group Discovery
* Active directory System Discovery
* Active directory User Discovery
* Heartbeat discovery
* Network discovery
When this method runs, it searches the local Active Directory forest, each trusted forest, and each additional forest that you configure in the Active Directory Forests node of the Configuration Manager console.
 
Use Active Directory Forest Discovery to :
 
   * Discover Active Directory sites and subnets, and then create Configuration Manager boundaries based on those network locations.
   * Identify supernets that are assigned to an Active Directory site. Convert each supernet into an IP address range boundary.
   * Publish to Active Directory Domain Services (AD DS) in a forest when publishing to that forest is enabled. The specified Active Directory Forest Account must have permissions to that forest.
 
You can manage Active Directory Forest Discovery in the Configuration Manager console. Go to the Administration workspace and expand Hierarchy Configuration.


Actions for Active Directory Forest Discovery are recorded in the following logs :
 
   * All actions, except actions related to publishing, are recorded in the ADForestDisc.Log file in the <InstallationPath>\Logs folder on the site server.
   * Active Directory Forest Discovery publishing actions are recorded in the hman.log and sitecomp.log files in the <InstallationPath>\Logs folder on the site server.
In addition to the information in this section, see Common features of Active Directory Group, System, and User Discovery.
 
Use this method to search Active Directory Domain Services to identify :
 
   * Local, global, and universal security groups.
   * The membership of groups.
   * Limited information about a group's member computers and users, even when another discovery method has not previously discovered those computers and users.
 
You can configure the following discovery scopes that control how this method searches for information :
 
Location : Use a location if you want to search one or more Active Directory containers. This scope option supports a recursive search of the specified Active Directory containers. This process searches each child container under the container that you specify. It continues until no more child containers are found.
 
Groups : Use groups if you want to search one or more specific Active Directory groups. You can configure Active Directory Domain to use the default domain and forest, or limit the search to an individual domain controller. Additionally, you can specify one or more groups to search. If you do not specify at least one group, all groups found in the specified Active Directory Domain location are searched.
 
Actions for Active Directory Group Discovery are recorded in the file adsgdis.log in the <InstallationPath>\LOGS folder on the site server.
By default, this Active Directory System Discovery method discovers basic information about the computer, including the following attributes :
 
* Computer name
* Operating system and version
* Active Directory container name
* IP address
* Active Directory site
* Time stamp of last logon
 
To successfully create a DDR for a computer, Active Directory System Discovery must be able to identify the computer account and then successfully resolve the computer name to an IP address.
 
In the Active Directory System Discovery Properties dialog box, on the Active Directory Attributes tab, you can view the full list of default object attributes that it discovers. You can also configure the method to discover additional (extended) attributes.
 
Actions for Active Directory System Discovery are recorded in the file adsysdis.log in the <InstallationPath>\LOGS folder on the site server.
Use this discovery method to search Active Directory Domain Services to identify user accounts and associated attributes. By default, this method discovers basic information about the user account, including the following attributes :
 
* User name
* Unique user name (includes domain name)
* Domain
* Active Directory container names
 
In the Active Directory User Discovery Properties dialog box, on the Active Directory Attributes tab, you can view the full default list of object attributes that it discovers. You can also configure the method to discover additional (extended) attributes.
 
Actions for Active Directory User Discovery are recorded in the file adusrdis.log in the <InstallationPath>\LOGS folder on the site server.
When Heartbeat Discovery runs, it creates a DDR that has the client's current information. The client then copies this small file (about 1 KB in size) to a management point so that a primary site can process it. The file has the following information:
 
  * Network location
  * NetBIOS name
  * Version of the client agent
  * Operational status details
 
Heartbeat Discovery is the only discovery method that provides details about the client installation status. It does so by updating the system resource client attribute to set a value equal to Yes.
 
Actions for Heartbeat Discovery are logged in the following locations :
 
   * For computer clients, Heartbeat Discovery actions are recorded on the client in the InventoryAgent.log file in the %Windir%\CCM\Logs folder.
   * For mobile device clients, Heartbeat Discovery actions are recorded in the DMPRP.log file in the %Program Files%\CCM\Logs folder of the management point that the mobile device client uses.
Use this method to discover the topology of your network and to discover devices on your network that have an IP address. Network Discovery searches your network for IP-enabled resources by querying the following entities :
 
* Servers that run a Microsoft implementation of DHCP
* Address Resolution Protocol (ARP) caches in network routers
* SNMP-enabled devices
* Active Directory domains
 
Network Discovery can return several attributes as part of the discovery record that it creates. These attributes include :
 
* NetBIOS name
* IP addresses
* Resource domain
* System roles
* SNMP community name
* MAC addresses
 
Network Discovery activity is recorded in the Netdisc.log file in <InstallationPath>\Logs on the site server that runs discovery.
Use Azure Active Directory (Azure AD) User Discovery to search your Azure AD subscription for users with a modern cloud identity. Azure AD user discovery can find the following attributes:
 
* objectId
* displayName
* mail
* mailNickname
* onPremisesSecurityIdentifier
* userPrincipalName
* AAD tenantID
* onPremisesDomainName
* onPremisesSamAccountName
* onPremisesDistinguishedName

This method supports full and delta synchronization of user attributes from Azure AD. This information can then be used along-side discovery data you collect from the other discovery methods.
 
Actions for Azure AD user discovery are recorded in the SMS_AZUREAD_DISCOVERY_AGENT.log file on the top-tier site server of the hierarchy.
You can discover user groups and members of those groups from Azure Active directory (Azure AD). Azure AD user group discovery can find the following attributes:
 
* objectId
* displayName
* mailNickname
* onPremisesSecurityIdentifier
* AAD tenantID

Actions for Azure AD user group discovery are recorded in the SMS_AZUREAD_DISCOVERY_AGENT.log file on the top-tier site server of the hierarchy.
In the Inventory module, you can view comprehensive details of the hardware and software of every Windows system on the network. Inventory in SCCM can be divided into the following: 
 
Hardware inventory : By using hardware inventory, you can gather data about the hardware configurations of clients' virtual machines in your entire organization.  
Software inventory : Software inventory can provide information about files on client devices. It can also record and analyze data from client devices on the site server.
* With System Center Configuration Manager 2012, a new concept called the content library was introduced.

* The content library stores everything related to Configuration Manager efficiently on the disk (distribution point). 
 
* Whenever the same file appears in two different packages, the content library only stores one copy of that file. There are, however, references indicating the file belongs to both packages.

* The content library is referred to as the "single-instance store" since it contains only one instance of any file. 

* By introducing the content library, we are maximizing storage space and avoiding the distribution of files that are already distributed on the distribution point, so we conserve bandwidth on the WAN.
* The BDP (Branch distribution points) cannot operate if they can't download content from the standard distribution point.

* Branch distribution points are instructed to download packages that have been assigned using client policies, then they download the content using standard client components.

* If the standard distribution point is configured as a protected site system, make sure the branch distribution point is included within the protected boundaries.
In SCCM, the Server Locator Points are used in the Configuration Manager to complete the client site assignment on an intranet. It also helps clients find management points when they cannot find the information through Active Directory Domain Services.
Following are the objects that can migrate from Configuration Manager 2007 to SCCM 2012 :
 
* Task sequences
* Configuration items
* Collections and boundaries
* Virtual application packages
* Packages distributing Software
* Software update deployment templates
* Configuration baselines etc.
Following is the list of key differences between SCCM & WSUS:

SCCM : 
*
SCCM is an acronym that stands for System Center Configuration Management or Manager.
* SCCM is used for pushing images of all types of operating systems.
* One of the key features of SCCM is that it offers asset management functionality.

WSUS : 
* WSUS is an acronym that stands for Windows Server Update Service.
* WSUS cannot push images for all types of operating systems.
* WSUS does not provide asset management functionality.
Intune is SCCM’s cloud-based mobile device and application management service. Unlike SCCM it is cloud native and is used to deliver software updates to mobile devices. It is part of Microsoft's Enterprise Mobility + Security (EMS) suite.
 
INTUNE PROS
* Cloud native
* Strong in Mobile Device Management (MDM)
* Good at light-weight, smaller applications on mobile devices or mobile OS.
* Auto provisioning of systems – with Microsoft Intune and Autopilot, you can give new devices to your end users without the need to build, maintain, and apply custom operating system images to the devices.
* When you use Intune to manage Autopilot devices, you can manage policies, profiles, apps after end users are enrolled
 
INTUNE CONS
* Narrow focus on mobile devices; not a full systems-management platform
* Doesn’t support server-side applications
* Not intended for large applications
* Doesn’t have the feature-set to handle complex package deployments
* Incurs egress or monthly usage fees based on the volume of data transmitted – software deployment is often a reactive activity based on the software provider updates; usage fees add up and get more expensive over time.
* Challenges in planning – difficult to predict the number or size of software updates that will occur over time, especially in an environment where most applications are going cloud native with a higher frequency of updates.
Following are the different prerequisites required for the Software update point: 
 
* Windows update agent 
* Windows Installer 
* Network load balancing 
* Site Server communication 
* Windows Server Update Services 
* Background Intelligent Transfer Server(BITS)
Communication between Configuration Manager sites must happen through one or more senders, and these senders can only be installed or deployed on primary or secondary site server systems.  SCCM has the following types of senders: 
 
Standard Sender : By default, all primary and secondary sites are configured with the standard sender. In the case of site-to-site communications over a LAN (Local Area Network) that uses a supported protocol, you do not have to install an additional sender. 
 
Courier Sender : Primary and secondary sites are all configured with the courier sender by default. However, it cannot be created or displayed in the Configuration Manager console. The reason for this is that you need to start it manually from the Configuration Manager programs folder on your Start menu. As opposed to sending data over the network, courier senders are essentially used for software distribution in order to send package data via physical media to another site.
SCCM deployment shares are basically repositories or places where you store OS images, language packs, applications, device drivers, and other software that needs to be deployed to target machines. MDT (Microsoft Deployment Toolkit) simplifies the deployment process by condensing the following two features into a single feature (the deployment share).  
 
Distribution share : This consists of operating system source files, application source files, out-of-box drivers and packages. 
Deployment point : This provides the necessary files for accessing the distribution share and installing a build from it.
A SCCM console is basically an administrative tool that administrators can use to perform a variety of tasks, including device management, application deployment, network and server administration, etc. SCCM admins can easily manage applications, packages, OS (Operating system) deployments, and many more administrative functions using SCCM Console.
To distribute the package, do the following steps:
 
* Write an install program, regarding the installation sources to create the package in the SCCM.
* To sync the contents, assign the distribution points to the package.
* Create a Collection, including the objects that allow us to receive packages.
* Create an Advertisement for distribution, to link with the collection, or to decide either an advertisement is required or not.
Asset Intelligence : Asset Intelligence in Configuration Manager identifies and manages the software you've stocked in your environment. It allows you to track and manage software license usage within your enterprise.  

Asset Tracking : Asset tracking is the process of tracking updates or packages of assets by collecting inventory data about the assets (both hardware and software). Following the installation of a required operating system and any subsequent updates or patches, such systems must be kept up to date with further timely updates or patches. With SCCM, you have access to tools for keeping track of the hardware and software assets of the system. 
The fallback status point always communicates with the clients over HTTP about installation failure. It uses unauthenticated connections and sends data in clear text that makes the fallback status point vulnerable to attack, particularly when used with internet-based client management.
Following is the list of various services required for the client computer to communicate with the server :
 
* Computer browser
* Windows installer
* SMS agent host
* Windows Management Instrumentation(WMI)
* Background Intelligence Transfer Server (BITS)
55 .
WMI is Windows Management Instrumentation. The WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM).
In SCCM, the database replication uses MySQL server to transfer data for settings and configure to other sites in the CM hierarchy.
The client policy is used to specify how often configuration manager clients download the following requirements:
 
* Windows OS computers (Servers, Desktops, Laptops, etc.)
* Mobile Devices
* Mac OS Computers
* Computers that run UNIX or Linux operating systems.
Native Mode :
*
In SCCMM, the Native mode is used for authentication and encryption.
* We can integrate the native mode with the public key infrastructure.

Mixed Mode : 
*
The mixed-mode is mainly used to locate the default management point of the client.
* We cannot integrate the mixed-mode with public key infrastructure.
NAP is an acronym for "Network Access Protection". It is a feature that leverages Windows 2008 to control which computer has access to a network.
In SCCM, WOL is an acronym for "Wake-On-LAN". This is a way to wake up a sleeping machine. It sends a magic packet to a computer to wake up and be ready to receive software updates.
The Azure AD device identity is a cloud-based identity that is used to secure the data with a management point and cloud management gateway.
Package Update : 
*
The Package update is used when the user made some changes in the source file.
* It can update the package version in the SQL
* A new PCK file is used for any other new DP’s
* It is a compressed package but is corrupt

Package Refresh : 
* The Package refresh is used to refresh a file.
* It can revise the old files
* No new PCK files were sent
* It creates a compressed file when we try to update the file.
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.
Troubleshooting OSD deployments can be frustrating. This degrades to downright impossible without logs to reference. Fortunately, we have the smsts.log to guide us. This log resides on the endpoint being built using your task sequence media.

 
* Windows PE before HDD format : x:\windows\temp\smstslog\smsts.log

*
Windows PE after HDD format : x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log

*
Full version Windows before SCCM agent installed : c:\_SMSTaskSequence\Logs\Smstslog\smsts.log

*
Full version Windows after SCCM agent installed : c:\windows\ccm\logs\Smstslog\smsts.log

*
Full version Windows (x64) after SCCM agent installed : c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log

*
After Task Sequence has finished running : c:\windows\ccm\logs\smsts.log

*
After Task Sequence has finished running (x64) : c:\windows\sysWOW64\ccm\logs\smsts.log
SMSTS.log is a log file that is used for troubleshooting operating system deployment issues and Task Sequence failures in SCCM.
 
When you notice that your SCCM task sequence fails, the first thing that you check is smsts.log file. While the TS sequence runs, you can open the smsts.log file by pressing the F8 key. Type CMTrace and you can view the smsts.log file.
 
If you press the F8 key and if the command prompt doesn’t appear, it means you haven’t enabled the command support for boot image.
The smsts.log file changes it location depending on the phase of the operating system installation you are in. As the task sequence progresses, the location of SMSTS.log file changes.
* CAS : Content Access Service. Maintains the local package cache.

* Ccmexec.log :
Records activities of the client and the SMS Agent Host service.

* CertificateMaintenance.log :
Maintains certificates for Active Directory service and management points.

* ClientIDManagerStartup.log :
Creates and maintains the client GUID.

* ClientLocation.log :
Site assignment tasks.

* ContentTransferManager.log :
Schedules the Background Intelligent Transfer Service (BITS) or the Server Message Block (SMB) to download or to access SMS packages.

* DataTransferService.log :
Records all BITS communication for policy or package access.

* Execmgr.log :
Records advertisements that run.

* FileBITS.log :
Records all SMB package access tasks.

* Fsinvprovider.log
(renamed to FileSystemFile.log in all SMS 2003 Service Packs) : Windows Management Instrumentation (WMI) provider for software inventory and file collection.

* InventoryAgent.log :
Creates discovery data records (DDRs) and hardware and software inventory records.

* LocationServices.log :
Finds management points and distribution points.

* Mifprovider.log :
The WMI provider for .MIF files.

* Mtrmgr.log :
Monitors all software metering processes.

* PolicyAgent.log :
Requests policies by using the Data Transfer service.

* PolicyAgentProvider.log :
Records policy changes.

* PolicyEvaluator.log :
Records new policy settings.

* Remctrl.log :
Logs when the remote control component (WUSER32) starts.

* Scheduler.log :
Records schedule tasks for all client operations.

* Smscliui.log :
Records usage of the Systems Management tool in Control Panel.

* StatusAgent.log :
Logs status messages that are created by the client components.

* SWMTRReportGen.log :
Generates a usage data report that is collected by the metering agent. (This data is logged in Mtrmgr.log.)
The Configuration Manager client for Mac computers records information in the following log files on the Mac computer.

CCMClient-date_time.log : Records activities that are related to the Mac client operations, including application management, inventory, and error logging. ( Location : /Library/Application Support/Microsoft/CCM/Logs)

CCMAgent-date_time.log : Records information that is related to client operations, including user sign in and sign out operations, and Mac computer activity. ( Location : ~/Library/Logs )

CCMNotifications-date_time.log : Records activities that are related to Configuration Manager notifications displayed on the Mac computer.( Location : ~/Library/Logs )

CCMPrefPane-date_time.log :  Records activities related to the Configuration Manager preferences dialog box on the Mac computer, which includes general status and error logging. ( Location : ~/Library/Logs )
* Ccm.log : Client Configuration Manager tasks.
* Cidm.log : Records changes to the client settings by the Client Install Data Manager (CIDM).
* Colleval.log : Logs when collections are created, changed, and deleted by the Collection Evaluator.
* Compsumm.log : Records Component Status Summarizer tasks.
* Cscnfsvc.log : Records Courier Sender confirmation service tasks.
* Dataldr.log : Processes Management Information Format (MIF) files and hardware inventory in the Configuration Manager 2007 database.
* Ddm.log : Saves DDR information to the Configuration Manager 2007 database by the Discovery Data Manager.
* Despool.log : Records incoming site-to-site communication transfers.
* Distmgr.log : Records package creation, compression, delta replication, and information updates.
* Hman.log : Records site configuration changes, and publishes site information in Active Directory Domain Services.
* Inboxast.log : Records files that are moved from the management point to the corresponding SMSINBOXES folder.
* Inboxmgr.log : Records file maintenance.
* Invproc.log : Records the processing of delta MIF files for the Dataloader component from client inventory files.
* Mpcontrol.log : Records the registration of the management point with WINS. Records the availability of the management point every 10 minutes.
* Mpfdm.log : Management point component that moves client files to the corresponding SMSINBOXES folder.
* MPMSI.log : Management point .msi installation log.
* MPSetup.log : Records the management point installation wrapper process.
* Ntsvrdis.log : Configuration Manager 2007 server discovery.
* Offermgr.log : Records advertisement updates.
* Offersum.log : Records summarization of advertisement status messages.
* Policypv.log : Records updates to the client policies to reflect changes to client settings or advertisements.
* Replmgr.log : Records the replication of files between the site server components and the Scheduler component.
* Rsetup.log : Reporting point setup log.
* Sched.log : Records site-to-site job and package replication.
* Sender.log : Records files that are sent to other child and parent sites.
* Sinvproc.log : Records client software inventory data processing to the site database in Microsoft SQL Server.
* Sitecomp.log : Records maintenance of the installed site components.
* Sitectrl.log : Records site setting changes to the Sitectrl.ct0 file.
* Sitestat.log : Records the monitoring process of all site systems.
* Smsdbmon.log : Records database changes.
* Smsexec.log : Records processing of all site server component threads.
* Smsprov.log : Records WMI provider access to the site database.
* SMSReportingInstall.log : Records the Reporting Point installation. This component starts the installation tasks and processes configuration changes.
* SMSSHVSetup.log : Records the success or failure (with failure reason) of installing the System Health Validator point.
* Srvacct.log : Records the maintenance of accounts when the site uses standard security.
* Statmgr.log : Writes all status messages to the database.
* Swmproc.log : Processes metering files and maintains settings.
The following log files that contain information related to SCCM site server installation.

* ConfigMgrPrereq.log : Records prerequisite component evaluation and installation activities
 
* ConfigMgrSetup.log : Records detailed output from the site server setup.
 
* ConfigMgrSetupWizard.log : Records information related to activity in the Setup Wizard.
 
* SMS_BOOTSTRAP.log : Records information about the progress of launching the secondary site installation process. Details of the actual setup process are contained in ConfigMgrSetup.log.
 
* smstsvc.log : Records information about the installation, use, and removal of a Windows service. Windows uses this service to test network connectivity and permissions between servers. It uses the computer account of the server that creates the connection.
Use the below log files to troubleshoot the Asset Intelligence related issues :

* AssetAdvisor.log : Records the activities of Asset Intelligence inventory actions. (Client Computer)

* aikbmgr.log :
Records details about the processing of XML files from the inbox for updating the Asset Intelligence catalog. (Site server)

* AIUpdateSvc.log :
Records the interaction of the Asset Intelligence sync point with the cloud service. (Site system server)

* AIUSMSI.log :
Records details about the installation of the Asset Intelligence sync point site system role. (Site system server)

* AIUSSetup.log :
Records details about the installation of the Asset Intelligence sync point site system role. (Site system server)

* ManagedProvider.log :
Records details about discovering software with an associated software identification tag. Also records activities related to hardware inventory. (Site system server)

* MVLSImport.log :
Records details about the processing of imported licensing files. (Site system server)
Use the below log files to troubleshoot issues related to Configuration Manager console :

* ConfigMgrAdminUISetup.log : Records the installation of the Configuration Manager console. ( Computer that runs the Configuration Manager console )

* SmsAdminUI.log : Records information about the operation of the Configuration Manager console. ( Computer that runs the Configuration Manager console )

* Smsprov.log : Records activities of the SMS Provider.  ( Site server or site system server )
Use the below log files to troubleshoot the issues related to your Management Point Server.
 
* CcmIsapi.log :  Records client messaging activity on the endpoint. Site system server. (Site system server)
* CCM_STS.log : Records activities for authentication tokens, either from Azure Active Directory or site-issued client tokens. Site system server. (Site system server)
* ClientAuth.log : Records signing and authentication activity. Site system server. (Site system server)
* MP_CliReg.log : Records the client registration activity processed by the management point. (Site system server)
* MP_Ddr.log : Records the conversion of XML.ddr records from clients, and copies them to the site server. (Site system server)
* MP_Framework.log : Records the activities of the core management point and client framework components. (Site system server)
* MP_GetAuth.log : Records the status of the site management points. (Site system server)
* MP_GetPolicy.log : Records policy information. (Site system server)
* MP_Hinv.log : Converts XML hardware inventory records from clients and copies the files to the site server. (Site system server)
* MP_Location.log : Records location manager tasks. (Site system server)
* MP_OOBMgr.log : Records the management point activities related to receiving an OTP from a client. (Site system server)
* MP_Policy.log : Records policy communication. (Site system server)
* MP_RegistrationManager.log : Records activities related to client registration, such as validating certificates, CRL, and tokens. (Site system server)
* MP_Relay.log : Copies files that are collected from the client.  (Site system server)
* MP_Retry.log : Records the hardware inventory retry processes. (Site system server)
* MP_Sinv.log : Converts XML hardware inventory records from clients and copies them to the site server. (Site system server)
* MP_SinvCollFile.log : Records details about file collection. (Site system server)
* MP_Status.log : Records details about the conversion of XML.svf status message files from clients and the copy of those files to the site server. (Site system server)
* mpcontrol.log : Records the registration of the management point with WINS. Records the availability of the management point every 10 minutes. (Site system server)
* mpfdm.log : Records the actions of the management point component that moves client files to the corresponding INBOXES folder on the site server. (Site system server)
* mpMSI.log : Records details about the management point installation. (Site server)
* MPSetup.log : Records the management point installation wrapper process. (Site server)
* UserService.log : Records user requests from Software Center, retrieving/installing user-available applications from the server. (Site system server)
 
The below log files contain information related to the data warehouse service point :
 
* DWSSMSI.log : Records messages generated by the installation of a data warehouse service point.  (Site system server)

* DWSSSetup.log :
Records messages generated by the installation of a data warehouse service point. (Site system server)

* Microsoft.ConfigMgrDataWarehouse.log :
Records information about data synchronization between the site database and the data warehouse database. (Site system server)
 
* FspIsapi.log : Records details about communications to the fallback status point from mobile device legacy clients and client computers. (Site system server)
 
* fspMSI.log : Records messages generated by the installation of a fallback status point. (Site system server)
 
* fspmgr.log : Records activities of the fallback status point site system role. (Site system server)
* DmCertEnroll.log : Records certificate enrollment data on mobile device clients.

* DMCertResp.htm (in temp) : Records HTML response from the certificate server when the mobile device Enroller program requests a client authentication certificate on mobile device clients.

* DmClientSetup.log : Records client setup data on mobile device clients.

* DmClientXfer.log : Records client transfer data for Windows Mobile Device Center and ActiveSync deployments.

* DmCommonInstaller.log : Records client transfer file installation for setting up mobile device client transfer files on client computers.

* DmInstaller.log : Records whether DMInstaller correctly calls DmClientSetup and whether DmClientSetup exits with success or failure on mobile device clients.

* DmInvExtension.log : Records Inventory Extension file installation for setting up Inventory Extension files on client computers.

* DmSvc.log : Records mobile device management service data on mobile device clients.
* DmClientHealth.log : Records the GUIDs of all the mobile device clients that are communicating with the Device Management Point.

* DmClientRegistration.log :
Records registration requests from and responses to the mobile device client in Native mode.

* DmpDatastore.log :
Records all the site database connections and queries made by the Device Management Point.

* DmpDiscovery.log :
Records all the discovery data from the mobile device clients on the Device Management Point.

* DmpFileCollection.log :
Records mobile device file collection data from mobile device clients on the Device Management Point.

* DmpHardware.log :
Records hardware inventory data from mobile device clients on the Device Management Point.

* DmpIsapi.log :
Records mobile device communication data from device clients on the Device Management Point.

* dmpMSI.log :
Records the MSI data for Device Management Point setup.

* DMPSetup.log :
Records the mobile device management setup process.

* DmpSoftware.log :
Records mobile device software distribution data from mobile device clients on the Device Management Point.

* DmpStatus.log :
Records mobile device status messages data from mobile device clients on the Device Management Point.

* FspIsapi.log :
Records Fallback Status Point communication data from mobile device clients and client computers on the Fallback Status Point.
You can refer to the below log files to troubleshoot SCCM operating system deployment issues :

* CAS.log : Records details when distribution points are found for referenced content.  (Location : Client Computer)
* ccmsetup.log : Provides information about client-based operating system actions. Can be used to troubleshoot client installation problems.  (Location : Client Computer)
* CreateTSMedia.log : Provides information about task sequence media when it is created. This log is generated on the computer running the Configuration Manager administrator console. (Location : Computer that runs Configuration Manager console.)
* Dism.log : Records driver installation actions or update application actions for offline servicing.  (Location : Site system server)
* Distmgr.log : Records details about the configuration of enabling a distribution point for Preboot Execution Environment (PXE).  (Location : Site system server)
* DriverCatalog.log : Records details about device drivers that have been imported into the driver catalog.  (Location : Site system server)
* mcsisapi.log : Records information for multicast package transfer and client request responses.  (Location : Site system server)
* mcsexec.log : Records health check, namespace, session creation, and certificate check actions.  (Location : Site system server)
* mcsmgr.log : Records changes to configuration, security mode, and availability.  (Location : Site system server)
* mcsprv.log : Records multicast provider interaction with Windows Deployment Services (WDS).  (Location : Site system server)
* MCSSetup.log : Records details about multicast server role installation.  (Location : Site system server)
* MCSMSI.log : Records details about multicast server role installation.  (Location : Site system server)
* Mcsperf.log : Records details about multicast performance counter updates.  (Location : Site system server)
* MP_ClientIDManager.log : Records management point responses to client ID requests that task sequences start from PXE or boot media.  (Location : Site system server)
* MP_DriverManager.log : Records management point responses to Auto Apply Driver task sequence action requests.  (Location : Site system server)
* OfflineServicingMgr.log : Records details of offline servicing schedules and update apply actions on operating system Windows Imaging Format (WIM) files.  (Location : Site system server)
* Setupact.log : Records details about Windows Sysprep and setup logs.  (Location : Client Computer)
* Setupapi.log : Records details about Windows Sysprep and setup logs.  (Location : Client Computer)
* Setuperr.log : Records details about Windows Sysprep and setup logs.  (Location : Client Computer)
* smpisapi.log : Records details about the client state capture and restore actions, and threshold information.  (Location : Client Computer)
* Smpmgr.log : Records details about the results of state migration point health checks and configuration changes.  (Location : Site system server)
* loadstate.log : Records details about the User State Migration Tool (USMT) and restoring user state data.  (Location : Client Computer)
* smpperf.log : Logs the state migration point performance counter updates.  (Location : Site system server)
* smspxe.log : Records details about the responses to clients that use PXE boot, and details about the expansion of boot images and boot files.  (Location : Site system server)
* smssmpsetup.log : Records installation and configuration details about the state migration point.  (Location : Site system server)
* SMS_PhasedDeployment.log : Log file for phased deployments. (Location : Top-level site in the Configuration Manager hierarchy)
* Smsts.log : General location for all operating system deployment and task sequence log events.  (Location : Client Computer)
* TSAgent.log : Records the outcome of task sequence dependencies before starting a task sequence.  (Location : Client Computer)
* smpmsi.log : Records installation and configuration details about the state migration point.  (Location : Site system server)
* TaskSequenceProvider.log : Provides information about task sequences when they are imported, exported, or edited.  (Location : Site system server)
* scanstate.log : Records details about the User State Migration Tool (USMT) and capturing user state data.  (Location : Client Computer)
* Ccmcca.log  : Logs the processing of compliance evaluation based on Configuration Manager NAP policy processing and contains the processing of remediation for each software update required for compliance.

* CIAgent.log  :  Tracks the process of remediation and compliance. However, the software updates log file, *Updateshandler.log – provides more informative details on installing the software updates required for compliance.

* locationservices.log  :  Used by other Configuration Manager features (for example, information about the client’s assigned site) but also contains information specific to Network Access Protection when the client is in remediation. It records the names of the required remediation servers (management point, software update point, and distribution points that host content required for compliance), which are also sent in the client statement of health.

* SDMAgent.log  :  Shared with the Configuration Manager feature desired configuration management and contains the tracking process of remediation and compliance. However, the software updates log file, Updateshandler.log, provides more informative details about installing the software updates required for compliance.

* SMSSha.log :  The main log file for the Configuration Manager Network Access Protection client and contains a merged statement of health information from the two Configuration Manager components: location services (LS) and the configuration compliance agent (CCA). This log file also contains information about the interactions between the Configuration Manager System Health Agent and the operating system NAP agent, and also between the Configuration Manager System Health Agent and both the configuration compliance agent and the location services. It provides information about whether the NAP agent successfully initialized, the statement of health data, and the statement of health response.
* Ccmperf.log : Contains information about the initialization of the System Health Validator point performance counters.
 
* SmsSHV.log : The main log file for the System Health Validator point; logs the basic operations of the System Health Validator service, such as the initialization progress.
 
* SmsSHVADCacheClient.log : Contains information about retrieving Configuration Manager health state references from Active Directory Domain Services.
 
* SmsSHVCacheStore.log : Contains information about the cache store used to hold the Configuration Manager NAP health state references retrieved from Active Directory Domain Services, such as reading from the store and purging entries from the local cache store file. The cache store is not configurable.
 
* SmsSHVRegistrySettings.log : Records any dynamic changes to the System Health Validator component configuration while the service is running.
 
* SmsSHVQuarValidator.log : Records client statement of health information and processing operations.
Use these SCCM log files when you troubleshoot issues related to desired configuration manager.
 
* ciagent.log : Provides information about downloading, storing, and accessing assigned configuration baselines.  (SCCM Site Server)

* dcmagent.log :
Provides high-level information about the evaluation of assigned configuration baselines and desired configuration management processes.  (SCCM Site Server)

* discovery.log :
Provides detailed information about the Service Modeling Language (SML) processes.  (SCCM Site Server)

* sdmagent.log :
Provides information about downloading, storing, and accessing configuration item content.  (SCCM Site Server)

* sdmdiscagent.log :
Provides high-level information about the evaluation process for the objects and settings configured in the referenced configuration items.  (SCCM Site Server)
Use these log files when you troubleshoot issues related to Wake on LAN.
 
* Wolmgr.log : Contains information about wake-up procedures such as when to wake up advertisements or deployments that are configured for Wake On LAN.  (Location : SCCM Site Server)

* WolCmgr.log : Contains information about which clients need to be sent wake-up packets, the number of wake-up packets sent, and the number of wake-up packets retried.  (Location : SCCM Site Server)
* ciamgr.log  : Provides information about the addition, deletion, and modification of software update configuration items.

* distmgr.log  : Provides information about the replication of software update deployment packages.

* objreplmgr.log  : Provides information about the replication of software updates notification files from a parent to child sites.

* PatchDownloader.log  : Provides information about the process for downloading software updates from the update source specified in the software updates metadata to the download destination on the site server.

* replmgr.log : Provides information about the process for replicating files between sites.

* smsdbmon.log  : Provides information about when software update configuration items are inserted, updated, or deleted from the site server database and creates notification files for software updates components.

* SUPSetup :  Provides information about the software update point installation. When the software update point installation completes, Installation was successful is written to this log file.

* WCM.log : Provides information about the software update point configuration and connecting to the Windows Server Update Services (WSUS) server for subscribed update categories, classifications, and languages.

* WSUSCtrl.log : Provides information about the configuration, database connectivity, and health of the WSUS server for the site.

* wsyncmgr.log : Provides information about the software updates synchronization process.
* CAS.log : Provides information about the process of downloading software updates to the local cache and cache management.

* CIAgent.log : Provides information about processing configuration items, including software updates.

* LocationServices.log : Provides information about the location of the WSUS server when a scan is initiated on the client.

* PatchDownloader.log : Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.

* PolicyAgent.log : Provides information about the process for downloading, compiling, and deleting policies on client computers.

* PolicyEvaluator : Provides information about the process for evaluating policies on client computers, including policies from software updates.

* RebootCoordinator.log : Provides information about the process for coordinating system restarts on client computers after software update installations.

* ScanAgent.log : Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.

* ScanWrapper : Provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients.

* SdmAgent.log : Provides information about the process for verifying and decompressing packages that contain configuration item information for software updates.

* ServiceWindowManager.log : Provides information about the process for evaluating configured maintenance windows.

* smscliUI.log : Provides information about the Configuration Manager Control Panel user interactions, such as initiating a Software Updates Scan Cycle from the Configuration Manager Properties dialog box, opening the Program Download Monitor, and so on.

* SmsWusHandler : Provides information about the scan process for the Inventory Tool for Microsoft Updates on SMS 2003 client computers.

* StateMessage.log : Provides information about when software updates state messages are created and sent to the management point.

* UpdatesDeployment.log : Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.

* UpdatesHandler.log : Provides information about software update compliance scanning and about the download and installation of software updates on the client.

* UpdatesStore.log : Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle.

* WUAHandler.log : Provides information about when the Windows Update Agent on the client searches for software updates.

* WUSSyncXML.log : Provides information about the Inventory Tool for the Microsoft Updates synchronization process. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.
The WSUS server log files are located in the %ProgramFiles%\Update Services\LogFiles folder.
 
* Change.log : Provides information about the WSUS server database information that has changed.  (Location : WSUS Server)

* SoftwareDistribution.log : Provides information about the software updates that are synchronized from the configured update source to the WSUS server database.  (Location : WSUS Server)
WindowsUpdate.log : Provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components.
* CBS.log : Records servicing failures related to changes for Windows Updates or roles and features.  (Location : Client Machine)

* DISM.log : Records all actions using DISM.  (Location : Client Machine)

* setupact.log : Primary log file for most errors that occur during the Windows installation process. The log file is located in the %windir%$Windows.~BT\sources\panther folder.  (Location : Client Machine)
* SMS_Cloud_ProxyConnector.log : Records details about setting up connections between the cloud management gateway service and the cloud management gateway connection point.  (This log file is located on site system server – C:\Program Files\Microsoft Configuration Manager\Logs)

* CloudMgr.log : This file logs details related to cloud management gateway service, ongoing service status, and all the data associated with the service.  (Location : On site server – C:\Program Files\Microsoft Configuration Manager\Logs)

* CMGContentService.log : This log records the details of the service when you enable a CMG to also serve content from Azure storage.  (Location : %approot%\logs on your Azure server)
 
* CMGService.log : Records details about the cloud management gateway (CMG) service core component in Azure.  (Location : %approot%\logs on your Azure server )
 
* CMGHttpHandler.log : This log has been removed. The component functionality is merged into the CMG service component. Therefore see the CMGService.log instead.  (Location : %approot%\logs on your Azure server )

* CMGSetup.log : Records details about the second phase of the cloud management gateway deployment (local deployment in Azure). (Location : %approot%\logs on your Azure server )
* M365AHandler.log : Logs information about the Desktop Analytics settings policy (Location : Client Machine – C:\Windows\CCM\Logs)
 
* M365AUploadWorker.log : Information about collection and device upload from Configuration Manager to Microsoft cloud  (Location : Service connection point)
 
* M365ADeploymentPlanWorker.log : Logs information about deployment plan sync from Desktop Analytics cloud service to on-premises SCCM  (Location : Service connection point)
 
* M365ADeviceHealthWorker.log : Information about device health upload from Configuration Manager to Microsoft cloud  (Location : Service connection point)
 
* SmsAdminUI.log : Information about Configuration Manager console activity, like configuring the Azure cloud services  (Location : Service connection point)
Troubleshooting Endpoint Analytics can be done with the following log files: 
 
* UXAnalyticsUploadWorker.log : Records data upload to the service for endpoint analytics.  (Location : Site server)

* SensorWmiProvider.log : Records the activity of the WMI provider for the endpoint analytics sensor.  (Location : Client)

* SensorEndpoint.log : Records the execution of endpoint analytics policy and upload of client data to the site server.  (Location : Client)

* SensorManagedProvider.log : Records the gathering and processing of events and information for endpoint analytics.  (Location : Client)
Listed below are the SCCM Endpoint Protection log files and locations :
 
* EndpointProtectionAgent.log : Records details about the installation of the Endpoint Protection client and the application of antimalware policy to that client.  (Location : Client)

* EPCtrlMgr.log : Records details about the syncing of malware threat information from the Endpoint Protection role server with the Configuration Manager database.  (Location : Site system server)

* EPMgr.log : Monitors the status of the Endpoint Protection site system role.  (Location : Site system server)

* EPSetup.log : Provides information about the installation of the Endpoint Protection site system role.  (Location : Site system server)
* easdisc.log : Records the activities and the status of the Exchange Server connector.  (Location : Site Server)
* pwrmgmt.log : Records details about power management activities on the client computer, including monitoring and the enforcement of settings by the Power Management Client Agent.  (Location :  Client Computer)
 
* hman.log : Records information about site configuration changes and the publishing of site information to Active Directory Domain Services.  (Location : Site server)

* SMSProv.log : Records WMI provider access to the site database.  (Location : Computer with the SMS Provider)
* mtrmgr.log : Monitors all software metering processes. (Location : Site server)
SCCM Server Logs Location : The SCCM server logs are located in DRIVE-Letter:\Program Files\Microsoft Configuration Manager\Logs.
 
SCCM Client Logs Location : The client logs are located in C:\Windows\CCM\Logs folder.
1. Using the Configuration Manager console, in the Software Library workspace, expand Operating Systems, right-click Task Sequences, and select Create Task Sequence.
 
2. On the Create a new task sequence page, select Upgrade an operating system from an upgrade package and click Next.
 
3. Use the following settings to complete the wizard:
 
* Task sequence name :  Upgrade Task Sequence
* Description : In-place upgrade
* Upgrade package : Windows 10 x64 RTM
* Include software updates : Do not install any software updates
* Install applications : OSD \ Adobe Acrobat Reader DC

4. Complete the wizard, and click Close.
 
5. Review the Upgrade Task Sequence.

In-Place Upgrade
In-place upgrade, which provides a simple, automated process that leverages the Windows setup process to automatically upgrade from an earlier version of Windows. This process automatically migrates existing data, settings, drivers, and applications.
 
Microsoft has built in extremely robust fallback options, if something goes wrong, the In-place Upgrade can easily reverting the Windows Update to the previous version by going back to an earlier build.The process can be automated and handled remotely with deployment tools.
SCCM OSD (Operating System Deployment) is one of the management solutions of SCCM family which can be used to deploy operating system on large number of systems in any organization’s network at a time.
 
We can configure this SCCM OSD solution in such a way that along with operating system deployment, system would be ready with all required softwares and settings which user would want on their system to work without putting any extra administrative overhead and efforts.
Either you deploy the operating system over the network or manually on a single system you would always need to have below prerequisites met before you go and install it,
 
* Boot Image
* OS Image
* Driver Package
* Software Package
 
 
Let us see more descriptive manner for understanding SCCM OSD prerequisites : 
 
* Need boot image to start the operating system deployment process on the devices and in some cases will have to add the network drivers to boot image.
* Enable PXE on the Distribution Site system
* Configured all required DHCP Scope option for PXE server
* Capture the image of reference computer either by capture task sequence or manual way by using DISM utility.
* Import capture image to SCCM and then distribute to distribution points.
* Create required package to be added in deployment task sequence.
* Distribute boot image, add on packages to distribution points.
* Add drivers for the identified device to the SCCM, create driver package and distribute to distribution points.
* Create task sequence with adding step for boot image, OS image, driver’s packages and add on other packages.
* Deploy task sequence to require collection.
* Monitor the deployment for the status.