sccm log files

Client Log Files

* 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 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.)

Server Log Files

* 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 SMS\INBOXES 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 SMS\INBOXES 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.


Admin Console Log Files

* RepairWizard.log - Records errors, warnings, and information about the process of running the Repair Wizard.
* ResourceExplorer.log - Records errors, warnings, and information about running the Resource Explorer.
* SMSAdminUI.log - Records the local Configuration Manager 2007 console tasks when you connect to Configuration Manager 2007 sites.

Management Point Log Files

* MP_Ddr.log - Records the conversion of XML.ddr records from clients, and copies them to the site server.
* MP_GetAuth.log - Records the status of the site management points.
* MP_GetPolicy.log - Records policy information.
* MP_Hinv.log - Converts XML hardware inventory records from clients and copies the files to the site server.
* MP_Location.log - Records location manager tasks.
* MP_Policy.log - Records policy communication.
* MP_Relay.log - Copies files that are collected from the client.
* MP_Retry.log - Records the hardware inventory retry processes.
* MP_Sinv.log - Converts XML hardware inventory records from clients and copies them to the site server.
* MP_Status.log - Converts XML.svf status message files from clients and copies them to the site server.

Mobile Device Management Log Files

* 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.

Mobile Device Client Log Files

* 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.

Operating System Deployment Log Files

* CCMSetup.log - Provides information about client-based operating system actions.
* CreateTSMedia.log - Provides information about task sequence media when it is created. This log is generated on the computer running the Configuration Manager 2007 administrator console.
* DriverCatalog.log - Provides information about device drivers that have been imported into the driver catalog.
* MP_ClientIDManager.log - Provides information about the Configuration Manager 2007 management point when it responds to Configuration Manager 2007 client ID requests from boot media or PXE. This log is generated on the Configuration Manager 2007 management point.
* MP_DriverManager.log - Provides information about the Configuration Manager 2007 management point when it responds to a request from the Auto Apply Driver task sequence action. This log is generated on the Configuration Manager 2007 management point.
* MP_Location.log - Provides information about the Configuration Manager 2007 management point when it responds to request state store or release state store requests from the state migration point. This log is generated on the Configuration Manager 2007 management point.
* Pxecontrol.log - Provides information about the PXE Control Manager.
* PXEMsi.log - Provides information about the PXE service point and is generated when the PXE service point site server has been created.
* PXESetup.log - Provides information about the PXE service point and is generated when the PXE service point site server has been created.
* Setupact.log Setupapi.log Setuperr.log Provide information about Windows Sysprep and setup logs.
* SmpIsapi.log - Provides information about the state migration point Configuration Manager 2007 client request responses.
* Smpmgr.log - Provides information about the results of state migration point health checks and configuration changes.
* SmpMSI.log - Provides information about the state migration point and is generated when the state migration point site server has been created.
* Smsprov.log - Provides information about the SMS provider.
* Smspxe.log - Provides information about the Configuration Manager 2007 PXE service point.
* SMSSMPSetup.log - Provides information about the state migration point and is generated when the state migration point site server has been created.
* Smsts.log - General location for all operating system deployment and task sequence log events.
* TaskSequenceProvider.log - Provides information about task sequences when they are imported, exported, or edited.
* USMT Log loadstate.log - Provides information about the User State Migration Tool (USMT) regarding the restore of user state data.
* USMT Log scanstate.log - Provides information about the USMT regarding the capture of user state data.

Network Access Protection Log Files

* 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.

System Health Validator Point Log Files

* 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. To obtain full information, change the registry key LogLevel from 1 to 0 in the following location:HKLM\SOFTWARE\Microsoft\SMSSHV\Logging\@GLOBAL

Desired Configuration Management Log Files

* ciagent.log - Provides information about downloading, storing, and accessing assigned configuration baselines.
* dcmagent.log - Provides high-level information about the evaluation of assigned configuration baselines and desired configuration management processes.
* discovery.log - Provides detailed information about the Service Modeling Language (SML) processes.
* sdmagent.log - Provides information about downloading, storing, and accessing configuration item content.
* sdmdiscagent.log - Provides high-level information about the evaluation process for the objects and settings configured in the referenced configuration items.

Wake On LAN Log Files

* Wolmgr.log - Contains information about wake-up procedures such as when to wake up advertisements or deployments that are configured for Wake On LAN.
* 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.


Software Updates Site Server Log Files

* 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.

WSUS Server Log Files

* Change.log - Provides information about the WSUS server database information that has changed.
* SoftwareDistribution.log - Provides information about the software updates that are synchronized from the configured update source to the WSUS server database.

Software Updates Client Computer Log Files

* 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.


Windows Update Agent Log File

* 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
-------------------
Thanks,
Paddy

sccm log files

Client Log Files

* 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 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.)

Server Log Files

* 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 SMS\INBOXES 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 SMS\INBOXES 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.


Admin Console Log Files

* RepairWizard.log - Records errors, warnings, and information about the process of running the Repair Wizard.
* ResourceExplorer.log - Records errors, warnings, and information about running the Resource Explorer.
* SMSAdminUI.log - Records the local Configuration Manager 2007 console tasks when you connect to Configuration Manager 2007 sites.

Management Point Log Files

* MP_Ddr.log - Records the conversion of XML.ddr records from clients, and copies them to the site server.
* MP_GetAuth.log - Records the status of the site management points.
* MP_GetPolicy.log - Records policy information.
* MP_Hinv.log - Converts XML hardware inventory records from clients and copies the files to the site server.
* MP_Location.log - Records location manager tasks.
* MP_Policy.log - Records policy communication.
* MP_Relay.log - Copies files that are collected from the client.
* MP_Retry.log - Records the hardware inventory retry processes.
* MP_Sinv.log - Converts XML hardware inventory records from clients and copies them to the site server.
* MP_Status.log - Converts XML.svf status message files from clients and copies them to the site server.

Mobile Device Management Log Files

* 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.

Mobile Device Client Log Files

* 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.

Operating System Deployment Log Files

* CCMSetup.log - Provides information about client-based operating system actions.
* CreateTSMedia.log - Provides information about task sequence media when it is created. This log is generated on the computer running the Configuration Manager 2007 administrator console.
* DriverCatalog.log - Provides information about device drivers that have been imported into the driver catalog.
* MP_ClientIDManager.log - Provides information about the Configuration Manager 2007 management point when it responds to Configuration Manager 2007 client ID requests from boot media or PXE. This log is generated on the Configuration Manager 2007 management point.
* MP_DriverManager.log - Provides information about the Configuration Manager 2007 management point when it responds to a request from the Auto Apply Driver task sequence action. This log is generated on the Configuration Manager 2007 management point.
* MP_Location.log - Provides information about the Configuration Manager 2007 management point when it responds to request state store or release state store requests from the state migration point. This log is generated on the Configuration Manager 2007 management point.
* Pxecontrol.log - Provides information about the PXE Control Manager.
* PXEMsi.log - Provides information about the PXE service point and is generated when the PXE service point site server has been created.
* PXESetup.log - Provides information about the PXE service point and is generated when the PXE service point site server has been created.
* Setupact.log Setupapi.log Setuperr.log Provide information about Windows Sysprep and setup logs.
* SmpIsapi.log - Provides information about the state migration point Configuration Manager 2007 client request responses.
* Smpmgr.log - Provides information about the results of state migration point health checks and configuration changes.
* SmpMSI.log - Provides information about the state migration point and is generated when the state migration point site server has been created.
* Smsprov.log - Provides information about the SMS provider.
* Smspxe.log - Provides information about the Configuration Manager 2007 PXE service point.
* SMSSMPSetup.log - Provides information about the state migration point and is generated when the state migration point site server has been created.
* Smsts.log - General location for all operating system deployment and task sequence log events.
* TaskSequenceProvider.log - Provides information about task sequences when they are imported, exported, or edited.
* USMT Log loadstate.log - Provides information about the User State Migration Tool (USMT) regarding the restore of user state data.
* USMT Log scanstate.log - Provides information about the USMT regarding the capture of user state data.

Network Access Protection Log Files

* 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.

System Health Validator Point Log Files

* 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. To obtain full information, change the registry key LogLevel from 1 to 0 in the following location:HKLM\SOFTWARE\Microsoft\SMSSHV\Logging\@GLOBAL

Desired Configuration Management Log Files

* ciagent.log - Provides information about downloading, storing, and accessing assigned configuration baselines.
* dcmagent.log - Provides high-level information about the evaluation of assigned configuration baselines and desired configuration management processes.
* discovery.log - Provides detailed information about the Service Modeling Language (SML) processes.
* sdmagent.log - Provides information about downloading, storing, and accessing configuration item content.
* sdmdiscagent.log - Provides high-level information about the evaluation process for the objects and settings configured in the referenced configuration items.

Wake On LAN Log Files

* Wolmgr.log - Contains information about wake-up procedures such as when to wake up advertisements or deployments that are configured for Wake On LAN.
* 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.


Software Updates Site Server Log Files

* 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.

WSUS Server Log Files

* Change.log - Provides information about the WSUS server database information that has changed.
* SoftwareDistribution.log - Provides information about the software updates that are synchronized from the configured update source to the WSUS server database.

Software Updates Client Computer Log Files

* 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.


Windows Update Agent Log File

* 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
-------------------
Thanks,
Paddy

Best Step by step from the site for SCCM

http://www.windows-noob.com/forums/index.php?/forum/71-reports/

Best Step by step from the site for SCCM

http://www.windows-noob.com/forums/index.php?/forum/71-reports/

Solar Power Technology

Yep I back after 10 years almost!!!!!!!!!!!!!!!!!!!!!!!!!!

 

Yes it's me MAD SOLOR MAD

Introduction: Most of the electricity in India comes from fossil-fuels like coal, oil and natural gas. Today the demand of electricity in India is increasing  where as the reserves of the fossil-fuel are depleting every day. The demand of electricity is already more than the production of electricity. We can feel this fact from the electricity-cuts during summer. Luckily Sun throws so much energy over India, that if can trap few minutes of solar energy falling over India we can provide India with electricity for whole year. Most parts of India get 7 KWH/ sq-meter of energy per day averaged over a year.

                We have gathered the most advanced techniques in solar world to provide cost efficient systems.  We are working towards our dream to eliminate the problem of electricity in India. This article gives a glance of our technology. This article does not have all the details of our technology and is a mere introduction.

Solar Cell :  A Solar cell is made up of silicon semiconductor wafer. The Solar cell generates current when light strikes on it. There are lots of technologies being used for PV cells today. Poly-Crystalline is the most widely used technology. As of today commercial  Solar cells have efficiency of 17% at max. Usually the poly-crystalline solar panels have 15 % efficiency. The power generated by a solar-cell is function of lots factors that are beyond the scope of this article. Our technology extracts every drop of  power from these solar panels to make our systems price-effective.

Solar Panel: A Solar panel is nothing but number of solar-cells connected in series and parallel to get desired voltage/current. Besides this, these solar cells are encapsulated in weather-proof material to guard the solar-cells against rain, hail , dust, wind etc. Most of solar panels are framed in aluminum-frame to provide structural re-enforcement and facilitate installation. PV arrays or panels are the most expensive part of the solar power system.

    We have done extensive research on Lead-Acid batteries and  Solar-cells to design optimum system that can give maximum efficiency and provide long life to batteries. Following are the few features of our systems.

1. Enhanced Solar Charge Controller: It seems very easy at first, hook the Solar Panels to battery or a load. But it is very complicated to extract energy from solar panels and feed it to batteries for use during night. The very first charge controllers just connected the solar panels to battery and switched off the panels when battery reached a specific voltage. Such systems waste significant part of the solar energy and kill the batteries. You can see that batteries used in inverters in homes die within 2-3 years where as battery life is much longer.

2. Temperature compensation: The characteristics of a Lead Acid battery change with battery temperature. The temperature of battery is decided by ambient temperature and the heat produced from internal resistance. For example a typical lead acid  battery is fully charged at 13.6 Volt at 45 Degree Celsius and 14.7 Volt at 0 Degree Celsius. India has extreme temperature conditions, during summer the temperature reaches 47 Degrees and in Winter it touches 5 Degrees. Under these conditions if we don't use temperature compensation we will overcharge the battery during summer resulting in excessive gassing and reduced battery life. During winter the battery will remain under-charged. Our systems monitor the battery temperature continuously and adjust the battery charging accordingly. 

3. Three stage battery charging: Our systems will use advanced three stage battery charge controllers to provide maximum efficiency and longer battery life. The three stage battery charger can be explained using simple analogy. The three stage charging is just like filling an empty pot with water. In starting we fill the pot with maximum speed and as the pot gets near to full , slow down the flow of water to gently top off the pot without spilling.

Bulk Stage. In the stage maximum current from the solar panels is transferred to batteries as inferred by the word "bulk".

Absorption Stage: In this stage, only that much charge is given to the battery as much battery can take. The battery is not forced to take the         charge it does not want to take.

Float: In this stage the battery is trickle charged to maintain the charge.

4. Batteries: Lead Acid batteries are most popular for storing electrical energy when the application is stationary. You would have seen the Lead Acid batteries used in inverters. Lead Acid batteries can be divided in two basic categories.

Automotive Battery: These batteries are used in  automobiles like cars, trucks for starting the engine. Lots of people use these batteries for inverters. These batteries are not suitable for inverters at all. These batteries are designed to provide high current for short time like starting the engine. If they are fully discharged repeatedly, just like in inverters, they will die soon. As you see most of cheap inverter batteries die in  2 years. Automotive batteries are designed for a discharge of 10%.

Deep Cycle Batteries: These batteries are designed for deep-discharging. These are the batteries designed for inverters and Solar Power systems. We will be using only high quality Deep-Cycle batteries in our system. These batteries are designed to provide low-current for long period and are built to survive deep-discharges. Our systems will provide a battery life of 7 years and above. There are further classifications in the deep-cycle batteries like flooded and VRLA etc. More details on the batteries are beyond the scope of this article.

5. Inverter:  The inverter is used to convert the DC power from solar panels to 220V AC. There are two types of inverters in the market

a) Modified sine Wave: These inverters produce modified sine wave. The harmonic distortion in these inverters can be as much 50%. These are cheaper and are and more efficient inverters. Most of the inverters used in homes are modified sine wave. These are good for most of the appliances. But if  these inverters are used for long time motors-based appliances run hotter. Also lots of appliances don't run on modified-sine wave at all like medical equipment.

b) Pure sine Wave: These inverters provide pure sine wave just like the mains power. These inverters have bit less efficiency than the modified sine wave, but these inverters can run all kind of appliances as these inverters provide pure sine wave. These are usually 2-3 times costlier than modified-sine wave inverters.

We are planning to use the pure-sine wave inverters in all major systems, so that all appliances  can run on the power they are designed for. Appliances run cooler, run silent on pure-sine wave inverters and enjoy a long life.
-------------------
Thanks,
Paddy

Solar Power Technology

Yep I back after 10 years almost!!!!!!!!!!!!!!!!!!!!!!!!!!

 

Yes it's me MAD SOLOR MAD

Introduction: Most of the electricity in India comes from fossil-fuels like coal, oil and natural gas. Today the demand of electricity in India is increasing  where as the reserves of the fossil-fuel are depleting every day. The demand of electricity is already more than the production of electricity. We can feel this fact from the electricity-cuts during summer. Luckily Sun throws so much energy over India, that if can trap few minutes of solar energy falling over India we can provide India with electricity for whole year. Most parts of India get 7 KWH/ sq-meter of energy per day averaged over a year.

                We have gathered the most advanced techniques in solar world to provide cost efficient systems.  We are working towards our dream to eliminate the problem of electricity in India. This article gives a glance of our technology. This article does not have all the details of our technology and is a mere introduction.

Solar Cell :  A Solar cell is made up of silicon semiconductor wafer. The Solar cell generates current when light strikes on it. There are lots of technologies being used for PV cells today. Poly-Crystalline is the most widely used technology. As of today commercial  Solar cells have efficiency of 17% at max. Usually the poly-crystalline solar panels have 15 % efficiency. The power generated by a solar-cell is function of lots factors that are beyond the scope of this article. Our technology extracts every drop of  power from these solar panels to make our systems price-effective.

Solar Panel: A Solar panel is nothing but number of solar-cells connected in series and parallel to get desired voltage/current. Besides this, these solar cells are encapsulated in weather-proof material to guard the solar-cells against rain, hail , dust, wind etc. Most of solar panels are framed in aluminum-frame to provide structural re-enforcement and facilitate installation. PV arrays or panels are the most expensive part of the solar power system.

    We have done extensive research on Lead-Acid batteries and  Solar-cells to design optimum system that can give maximum efficiency and provide long life to batteries. Following are the few features of our systems.

1. Enhanced Solar Charge Controller: It seems very easy at first, hook the Solar Panels to battery or a load. But it is very complicated to extract energy from solar panels and feed it to batteries for use during night. The very first charge controllers just connected the solar panels to battery and switched off the panels when battery reached a specific voltage. Such systems waste significant part of the solar energy and kill the batteries. You can see that batteries used in inverters in homes die within 2-3 years where as battery life is much longer.

2. Temperature compensation: The characteristics of a Lead Acid battery change with battery temperature. The temperature of battery is decided by ambient temperature and the heat produced from internal resistance. For example a typical lead acid  battery is fully charged at 13.6 Volt at 45 Degree Celsius and 14.7 Volt at 0 Degree Celsius. India has extreme temperature conditions, during summer the temperature reaches 47 Degrees and in Winter it touches 5 Degrees. Under these conditions if we don't use temperature compensation we will overcharge the battery during summer resulting in excessive gassing and reduced battery life. During winter the battery will remain under-charged. Our systems monitor the battery temperature continuously and adjust the battery charging accordingly. 

3. Three stage battery charging: Our systems will use advanced three stage battery charge controllers to provide maximum efficiency and longer battery life. The three stage battery charger can be explained using simple analogy. The three stage charging is just like filling an empty pot with water. In starting we fill the pot with maximum speed and as the pot gets near to full , slow down the flow of water to gently top off the pot without spilling.

Bulk Stage. In the stage maximum current from the solar panels is transferred to batteries as inferred by the word "bulk".

Absorption Stage: In this stage, only that much charge is given to the battery as much battery can take. The battery is not forced to take the         charge it does not want to take.

Float: In this stage the battery is trickle charged to maintain the charge.

4. Batteries: Lead Acid batteries are most popular for storing electrical energy when the application is stationary. You would have seen the Lead Acid batteries used in inverters. Lead Acid batteries can be divided in two basic categories.

Automotive Battery: These batteries are used in  automobiles like cars, trucks for starting the engine. Lots of people use these batteries for inverters. These batteries are not suitable for inverters at all. These batteries are designed to provide high current for short time like starting the engine. If they are fully discharged repeatedly, just like in inverters, they will die soon. As you see most of cheap inverter batteries die in  2 years. Automotive batteries are designed for a discharge of 10%.

Deep Cycle Batteries: These batteries are designed for deep-discharging. These are the batteries designed for inverters and Solar Power systems. We will be using only high quality Deep-Cycle batteries in our system. These batteries are designed to provide low-current for long period and are built to survive deep-discharges. Our systems will provide a battery life of 7 years and above. There are further classifications in the deep-cycle batteries like flooded and VRLA etc. More details on the batteries are beyond the scope of this article.

5. Inverter:  The inverter is used to convert the DC power from solar panels to 220V AC. There are two types of inverters in the market

a) Modified sine Wave: These inverters produce modified sine wave. The harmonic distortion in these inverters can be as much 50%. These are cheaper and are and more efficient inverters. Most of the inverters used in homes are modified sine wave. These are good for most of the appliances. But if  these inverters are used for long time motors-based appliances run hotter. Also lots of appliances don't run on modified-sine wave at all like medical equipment.

b) Pure sine Wave: These inverters provide pure sine wave just like the mains power. These inverters have bit less efficiency than the modified sine wave, but these inverters can run all kind of appliances as these inverters provide pure sine wave. These are usually 2-3 times costlier than modified-sine wave inverters.

We are planning to use the pure-sine wave inverters in all major systems, so that all appliances  can run on the power they are designed for. Appliances run cooler, run silent on pure-sine wave inverters and enjoy a long life.
-------------------
Thanks,
Paddy

Deleting Invalid SMS 2003 Distribution Points

Deleting Invalid SMS 2003 Distribution Points

If a server is decommissioned before removing SMS, orphaned Distribution Points are left in the SMS 2003 database. This becomes apparent in the SMS Administrator Console when trying to add a package to a Distribution Point, showing blank DP entries.

This post provides information on methods to cleanse the SMS database, with all methods going through the SMS provider.

Method 1 - Use the CleanDP.vbs VBScript

cscript CleanDP.vbs %server%

Method 2 - Use WMIC

Query for the distribution points for the server:

wmic /namespace:\\root\sms\site_%sitecode% /node:%server% path sms_distributionpoint WHERE "ServerNALPath like '%serverToDelete%'" get *

And then execute the delete method against the distribution point:

wmic /namespace:\\root\sms\site_%sitecode% server% path sms_distributionpoint WHERE "ServerNALPath like '%serverToDelete%'" delete

Note that the delete command can be quite powerful, use the /interactive:on global switch to prompt for each deletion.

Method 3 - Use the WMI CIM Studio

The Microsoft WMI CIM Studio application provides a GUI interface for WMI management, allowing connections to servers and paths, along with executing WQL queries and providing the possibility of deleting the result set.

' -- CleanDP.vbs
'
' Update strSiteServer and strSiteCode, and uncomment the objDP.Delete_ line
'
strSiteServer = "SERVER"
  strSiteCode = "AAA"

If WScript.Arguments.UnNamed.Count = 1 Then
 strServer = WScript.Arguments.UnNamed(0)
Else
 WScript.Echo "Provide a server to delete all the packages from"
 WScript.Quit(2)
  End If 

wscript.echo strserver

Set objNameSpace = GetObject("winmgmts:" & "\\" & strSiteServer & "\root\sms\site_" & strSiteCode)

strQuery =  "SELECT * " & _
    "FROM SMS_DistributionPoint " & _
  "WHERE ServerNalPath Like '%" & strServer & "%'"

Set objDPSet = objNameSpace.ExecQuery(strQuery)
For each objDP in objDPSet
   wscript.echo objDP.PackageID & ", " & objDP.SiteCode & ", " & objDP.ServerNALPath & ", " & objDP.Status
 'objDP.Delete_
Next 

-------------------
Enjoy,

Deleting Invalid SMS 2003 Distribution Points

Deleting Invalid SMS 2003 Distribution Points

If a server is decommissioned before removing SMS, orphaned Distribution Points are left in the SMS 2003 database. This becomes apparent in the SMS Administrator Console when trying to add a package to a Distribution Point, showing blank DP entries.

This post provides information on methods to cleanse the SMS database, with all methods going through the SMS provider.

Method 1 - Use the CleanDP.vbs VBScript

cscript CleanDP.vbs %server%

Method 2 - Use WMIC

Query for the distribution points for the server:

wmic /namespace:\\root\sms\site_%sitecode% /node:%server% path sms_distributionpoint WHERE "ServerNALPath like '%serverToDelete%'" get *

And then execute the delete method against the distribution point:

wmic /namespace:\\root\sms\site_%sitecode% server% path sms_distributionpoint WHERE "ServerNALPath like '%serverToDelete%'" delete

Note that the delete command can be quite powerful, use the /interactive:on global switch to prompt for each deletion.

Method 3 - Use the WMI CIM Studio

The Microsoft WMI CIM Studio application provides a GUI interface for WMI management, allowing connections to servers and paths, along with executing WQL queries and providing the possibility of deleting the result set.

' -- CleanDP.vbs
'
' Update strSiteServer and strSiteCode, and uncomment the objDP.Delete_ line
'
strSiteServer = "SERVER"
  strSiteCode = "AAA"

If WScript.Arguments.UnNamed.Count = 1 Then
 strServer = WScript.Arguments.UnNamed(0)
Else
 WScript.Echo "Provide a server to delete all the packages from"
 WScript.Quit(2)
  End If 

wscript.echo strserver

Set objNameSpace = GetObject("winmgmts:" & "\\" & strSiteServer & "\root\sms\site_" & strSiteCode)

strQuery =  "SELECT * " & _
    "FROM SMS_DistributionPoint " & _
  "WHERE ServerNalPath Like '%" & strServer & "%'"

Set objDPSet = objNameSpace.ExecQuery(strQuery)
For each objDP in objDPSet
   wscript.echo objDP.PackageID & ", " & objDP.SiteCode & ", " & objDP.ServerNALPath & ", " & objDP.Status
 'objDP.Delete_
Next 

-------------------
Enjoy,

DP Basics to Advanced- Step by Step

 

 

I will start with the basics here:

Requirements

• OS - Windows Server 2000 SP4 or newer. Although not supported, in small offices you can sometimes get away with using a Windows XP desktop. There is a limit to 10 connections on a share, so this should only be used in offices with less than 10, and be thoroughly tested before put into production.
  
• Permissions - SMS Site Server added to local Admin group on the server targeted to be the DP, and if a file share is used, the local admin group should have full rights, and authenticated users grated read permissions. This will ensure that the system accounts on the targeted PCs can access the packages.
  

Optional:

• IIS installed with WebDav enabled – this is required if you are going to use BITS on the DP. Depending on the connection to targeted clients this may be a nice thing to have, but you must also consider the security risks of having IIS installed, and lock it down accordingly. This will allow the site to control the rate at which the package is copied to the local cache on the client, and allow the client to resume the download if the connection is lost instead of beginning the download again from scratch. This should be considered for any DP that remote, VPN, and Dialup users will use.
  

Considerations:
When choosing a server for a DP, and deciding whether to use a file share or accessing the entire server you must consider your end result. If you add the server, you will be giving SMS access to all drives, and creating a package share on each NTFS formatted drive, unless you create an empty file named No_SMS_on_drive.sms and place it on the root of that drive. SMS will place the packages on the drive that has the most free space available. This may change as drive space changes. If you are going to use this server for anything else besides a DP, such as a Reporting Point, you will have to add it as a site system. If you add a share you have created, you will force SMS to always use that location. This can be helpful if you need to ensure the path does not change from one DP to another, or you want to be able to find where the packages are being copied. I typically use a share called SMSPKG on all my file servers for this reason.

The second item, and maybe it should be the first, is space. My 1st DP only had 50 Gig of free space, and to this day I could still survive with that so long as I do not put my OSD images there. I now require a minimum of 40 Gig free on all DPs, and 250 Gig on my site server for packages. This is because I have all packages on my site server, but only what is needed on the other DPs. The big question is how much space are you going to need 2-3 years from now. There are some calculations out there but it all comes down to how much you need today, and how much will you grow. Between OSD images, Office packages, and 50-100 other applications you will need to have available in your site for your company, I believe the standard is to allow enough room for your package repositories to double in size. I know some companies require over 250 Gig on all DPs due to the amount of packages required for day to day business.

Last is which site you want to add the DP to. If you have only one site this is not an issue, but if you have multiple sites, you will need to create the DP in the same site as the clients it will serve. DPs from a child are visible to the parent site(s) so they can assign packages, but a child site cannot see or assign packages to DPs on a parent site.

Standard DP:

• Add site server to local Administrators group on the select server
  
• Create a share (If needed) and set permissions
  
• Create an empty file named No_SMS_on_drive.sms and place it in the root of any drives you do not want used for packages if adding as a site system
  
• From the SMS Console, go to
  System Management Server\Site Database\Site Hierarchy\"Site Name"\Site Settings\Site Systems
  
• Right click on Site Systems, and choose New, Server (or Server Share depending on you need)
  
• Click Set and enter the server name and share depending on your selection above, and click OK.
  
• If you are running 2003 SP2, and have extended the schema, click Specify a Fully Qualified Host Name. This will allow clients to find the site systems using DNS, reducing network traffic.
  
• Click the Distribution Point tab
  
• Click Use this site system as a distribution point, this will enable the system as a DP
  
• Click Enable BITS if you have IIS installed, and wish to use BITSs to send package
  

Protected DP:
Although Microsoft does not come out and say this, any remote DP should be protected unless you want to risk clients pulling their packages across WAN links, or you have 10+ Meg connections to all your offices. SMS 2003 is better at finding local DPs, but we will always get a black eye if we cause even one bandwidth issue. It is better if you can tell management that you know without a doubt that SMS is not filling up the pipe between offices.

• Click Enable as a protected distribution point
  
• Click the Configure boundaries button
  
• Click the starburst button to add boundaries
  
• Select the boundaries for your DP. You can select multiples if you use the Shift or CTRL key when you are clicking on the IDs, and click OK. Only boundaries specified for the site will be visible. If you are using AD Sites for your SMS Site boundaries, you will only see those sites listed as options for your DP. If you wish to use subnets for your boundaries that are not listed, you will need to add them to your SMS Site or Roaming boundaries.
  

Group membership:
You can add DPs to groups to make it easier to add large numbers of DPs to a package. This is very handy when you assign packages to certain DPs based on business use, department, locations, etc.. I have groups set up for Security Patches, and Sites so that when I create a package I can use the select group option and get all the DPs I need instead of selecting them one at a time.

From the Distribution Point tab in the Site System properties

To create a new Group:

• Click on the starburst button
  
• Enter the name of the new group
  
• Click include this site system in this distribution point group
  
• Click OK
  

To add a DP to an existing Group:

• Click on the Group
  
• Click the Change Membership button this will change entry for member to yes or no depending on the current value
  
• You can also click the Properties button, and then click Include this system in this distribution point group. This window will also show you all the other systems that are currently members of this group.
  

Known Issue:
Antivirus may block copying of INF files; we have had to turn off scanning of the SMS Package folders when using McAfee. I do not recommend removing the Antivirus on any server or desktop as a resolution to any issue. If you run into problems with SMS accessing your DP, you may want to check your antivirus solution to ensure that it is not blocking access to the DP based on behavior such as remote access via HTTP, or a package that has a .INF (such as drivers in an OSD package).

Troubleshooting:
Once you have successfully added a DP, or any other site system, you should be able to see the status for this site in the Site Database\System Status\Site Status\"Site name"\Site System Status screen. The status should be listed as OK, and you should also see drive statistics such as free space.

A second place to look is SMS_SITE_COMPONENT_MANAGER. 1014 will show the system is being installed, and a 1015 message will indicate success for installing the site system. Any errors should be checked against the message codes in the download below from Microsoft.

If you have successfully created the DP, but your package is not being uploaded to the DP, check the message on the SMS_DISTRIBUTION_MANAGER component. If you are seeing access denied messages, they are most likely due to one of two issues; Antivirus is blocking the package(or part of it), or someone has changed the permissions on the DP.
-------------------
Enjoy,
26

DP Basics to Advanced- Step by Step

 

 

I will start with the basics here:

Requirements

• OS - Windows Server 2000 SP4 or newer. Although not supported, in small offices you can sometimes get away with using a Windows XP desktop. There is a limit to 10 connections on a share, so this should only be used in offices with less than 10, and be thoroughly tested before put into production.
  
• Permissions - SMS Site Server added to local Admin group on the server targeted to be the DP, and if a file share is used, the local admin group should have full rights, and authenticated users grated read permissions. This will ensure that the system accounts on the targeted PCs can access the packages.
  

Optional:

• IIS installed with WebDav enabled – this is required if you are going to use BITS on the DP. Depending on the connection to targeted clients this may be a nice thing to have, but you must also consider the security risks of having IIS installed, and lock it down accordingly. This will allow the site to control the rate at which the package is copied to the local cache on the client, and allow the client to resume the download if the connection is lost instead of beginning the download again from scratch. This should be considered for any DP that remote, VPN, and Dialup users will use.
  

Considerations:
When choosing a server for a DP, and deciding whether to use a file share or accessing the entire server you must consider your end result. If you add the server, you will be giving SMS access to all drives, and creating a package share on each NTFS formatted drive, unless you create an empty file named No_SMS_on_drive.sms and place it on the root of that drive. SMS will place the packages on the drive that has the most free space available. This may change as drive space changes. If you are going to use this server for anything else besides a DP, such as a Reporting Point, you will have to add it as a site system. If you add a share you have created, you will force SMS to always use that location. This can be helpful if you need to ensure the path does not change from one DP to another, or you want to be able to find where the packages are being copied. I typically use a share called SMSPKG on all my file servers for this reason.

The second item, and maybe it should be the first, is space. My 1st DP only had 50 Gig of free space, and to this day I could still survive with that so long as I do not put my OSD images there. I now require a minimum of 40 Gig free on all DPs, and 250 Gig on my site server for packages. This is because I have all packages on my site server, but only what is needed on the other DPs. The big question is how much space are you going to need 2-3 years from now. There are some calculations out there but it all comes down to how much you need today, and how much will you grow. Between OSD images, Office packages, and 50-100 other applications you will need to have available in your site for your company, I believe the standard is to allow enough room for your package repositories to double in size. I know some companies require over 250 Gig on all DPs due to the amount of packages required for day to day business.

Last is which site you want to add the DP to. If you have only one site this is not an issue, but if you have multiple sites, you will need to create the DP in the same site as the clients it will serve. DPs from a child are visible to the parent site(s) so they can assign packages, but a child site cannot see or assign packages to DPs on a parent site.

Standard DP:

• Add site server to local Administrators group on the select server
  
• Create a share (If needed) and set permissions
  
• Create an empty file named No_SMS_on_drive.sms and place it in the root of any drives you do not want used for packages if adding as a site system
  
• From the SMS Console, go to
  System Management Server\Site Database\Site Hierarchy\"Site Name"\Site Settings\Site Systems
  
• Right click on Site Systems, and choose New, Server (or Server Share depending on you need)
  
• Click Set and enter the server name and share depending on your selection above, and click OK.
  
• If you are running 2003 SP2, and have extended the schema, click Specify a Fully Qualified Host Name. This will allow clients to find the site systems using DNS, reducing network traffic.
  
• Click the Distribution Point tab
  
• Click Use this site system as a distribution point, this will enable the system as a DP
  
• Click Enable BITS if you have IIS installed, and wish to use BITSs to send package
  

Protected DP:
Although Microsoft does not come out and say this, any remote DP should be protected unless you want to risk clients pulling their packages across WAN links, or you have 10+ Meg connections to all your offices. SMS 2003 is better at finding local DPs, but we will always get a black eye if we cause even one bandwidth issue. It is better if you can tell management that you know without a doubt that SMS is not filling up the pipe between offices.

• Click Enable as a protected distribution point
  
• Click the Configure boundaries button
  
• Click the starburst button to add boundaries
  
• Select the boundaries for your DP. You can select multiples if you use the Shift or CTRL key when you are clicking on the IDs, and click OK. Only boundaries specified for the site will be visible. If you are using AD Sites for your SMS Site boundaries, you will only see those sites listed as options for your DP. If you wish to use subnets for your boundaries that are not listed, you will need to add them to your SMS Site or Roaming boundaries.
  

Group membership:
You can add DPs to groups to make it easier to add large numbers of DPs to a package. This is very handy when you assign packages to certain DPs based on business use, department, locations, etc.. I have groups set up for Security Patches, and Sites so that when I create a package I can use the select group option and get all the DPs I need instead of selecting them one at a time.

From the Distribution Point tab in the Site System properties

To create a new Group:

• Click on the starburst button
  
• Enter the name of the new group
  
• Click include this site system in this distribution point group
  
• Click OK
  

To add a DP to an existing Group:

• Click on the Group
  
• Click the Change Membership button this will change entry for member to yes or no depending on the current value
  
• You can also click the Properties button, and then click Include this system in this distribution point group. This window will also show you all the other systems that are currently members of this group.
  

Known Issue:
Antivirus may block copying of INF files; we have had to turn off scanning of the SMS Package folders when using McAfee. I do not recommend removing the Antivirus on any server or desktop as a resolution to any issue. If you run into problems with SMS accessing your DP, you may want to check your antivirus solution to ensure that it is not blocking access to the DP based on behavior such as remote access via HTTP, or a package that has a .INF (such as drivers in an OSD package).

Troubleshooting:
Once you have successfully added a DP, or any other site system, you should be able to see the status for this site in the Site Database\System Status\Site Status\"Site name"\Site System Status screen. The status should be listed as OK, and you should also see drive statistics such as free space.

A second place to look is SMS_SITE_COMPONENT_MANAGER. 1014 will show the system is being installed, and a 1015 message will indicate success for installing the site system. Any errors should be checked against the message codes in the download below from Microsoft.

If you have successfully created the DP, but your package is not being uploaded to the DP, check the message on the SMS_DISTRIBUTION_MANAGER component. If you are seeing access denied messages, they are most likely due to one of two issues; Antivirus is blocking the package(or part of it), or someone has changed the permissions on the DP.
-------------------
Enjoy,
26

No_SMS_on_drive.sms

No_SMS_on_drive.sms
-------------------

No_SMS_on_drive.sms

No_SMS_on_drive.sms
-------------------