I have been often come across discussion where my friends differs about the macro idea about Heatbeat discovery resulting into beating my heart. So here is crux of what exact a heartbeat is. Below are the information contained as part of Heartbeat Discovery. Is the client installed? Client type (Legacy, Advanced, or Device) Client version NetBIOS Name Character encoding used by the client Default system locale identifier (typically representative of the client’s language) Date and time of the DDR Date and time of last DDR Short name of system Currently logged in (interactive) user FQDN of system IP Network ID Platform ID (this is an encoding of the OS version) AD Site Name IP Address(es) MAC Address(es) Domain name Assigned (Primary) Site Hardware ID Identifying number (computer system) Product name (computer system) UUID (of the computer system) Version (computer system) Heartbeat Discovery messages are quite small and have negligible overhead on the client. Cumulatively, a large number could impact an under-powered management point, however, so setting them too frequently is not advisable. Out of the box, the default is 7 days. I typically set this down to every 1 day and know others do it even more often. I would never recommend setting this to less than 1 or 2 hours except in very small environments – there isn’t really any value in doing so anyway as nothing in the above list normally changes that frequently. The Heartbeat Discovery also serves as a “keep alive” or “yes I am alive” message from the client to the site server. Based on this, the Clear Install Flag and Delete Aged Discovery Data maintenance tasks perform their jobs. Note that the Delete Inactive Client Discovery Data does not directly use the heartbeat time. Instead, Client Status Reporting (available in R2 and R3), uses the last heartbeat time along with last hardware inventory, last software inventory, and last policy polling time to determine if a client is inactive. Once a client is marked inactive by Client Status Reporting, it is then subject to the Delete Inactive Client Discovery Data task. This “keep alive” purpose of the heartbeat discovery should also influence your choice of how often to set the interval; i.e., you shouldn’t set so infrequently that it might get accidentally marked inactive or not installed by one of the above mentioned maintenance tasks. Note that you can manually initiate a Heartbeat Discovery anytime on a client from the Configuration Manager Control Panel applet by navigating to the actions tab, selecting Discovery Data Collection Cycle, and then pushing the Initiate Action button. Heartbeat Discovery forces the rediscovery of active clients that have been deleted from the Configuration Manager database by the administrator, or by a database maintenance task. If you accidentally delete a computer from the Configuration Manager console, it will automatically "come back" if it is still active on the network. You can either wait for the next Heartbeat Discovery cycle to run, or you can hurry things along by selecting the Discovery Data Collection Cycle on the client Configuration Manager Properties: Actions tab, and click OK. Heartbeat Discovery is the discovery process that submits a client's installation status to its assigned site. The client might be installed but the client state in the Configuration Manager console continues to display No for its Client state if the site hasn't received the client's discovery data record (DDR) from Heartbeat Discovery. This will be the case if the client cannot communicate with its management point.
The Windows Installer CreatingCustomReportsByUsingSQLViews.msi package provides information that will help you to create custom reports, determine which Configuration Manager SQL views contain the information you need for your reports, and identify a path between the necessary SQL views and determine what columns can be used to join them.
Few months back my patching team comaplins that during patch cycle the MMC get hanged and become unresponsive. During patch cycle thousands of computers needs to be quried to put in a collection. This usually happens in large SCCM environment. Here is the resolution.
Go to the adminUI.log and find the ErrorCode = 2152205056
if this is the error then fillow the below steps -
1. Run WBEMTest and connect to Root.
2. Click 'Open Instance', enter __ProviderHostQuotaConfiguration=@ and click OK.
3. Locate the MemoryPerHost property and double click it to bring up the editor.
4. Change the value to 536870912 and click Save Property. [Note: 536870912 is 512MB written in Bytes. 5. Locate the HandlesPerHost property, note the current value, set it to 8192 and click Save Property.
6. Click Save Object, exit WBEMTest and reboot the site server and test again.
Note : Make sure that you have saved the curren value some where.
You may have received error from wsyncmgr.log stating " Sync failed: LocalDBOtherError: SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.~~at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e). Source: Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction" You can Resolve the issue in following ways - ReIndex the WSUS 3.0atabase http://gallery.technet.microsoft.com/ScriptCenter/en-us/6f8cde49-5c52-4abd-9820-f1d270ddea61 -Run WSUS Cleanup wizard Run the WSUS Server Clean-up Wizard from the bottom of the WSUS hierarchy to the top and NEVER from the top down. Run the WSUS Server Clean-Up Wizard throughout the hierarchy on a monthly basis. http://gallery.technet.microsoft.com/ScriptCenter/en-us/fd39c7d4-05bb-4c2d-8a99-f92ca8d08218 ------------------OR-------------------- -Open WSUS administration console, select Options, and then Server Cleanup Wizard -This wizard will remove unneeded content and computers that have not contacted the server for 30 days(Default) or more. Select all possible options, and then click Next. - It will begin the cleanup process, and will present a summary of its work when it is finished. Click Finish to complete the process
This happens If Active Directory Schema is not extended and the computer holding SCCM server does not have full rights on Active directory container. This can be rectified in following way... -open Active Directory Users and Computers. -On the View menu, click Advanced Features. The Active Directory Computers and Users window displays additional Active Directory information, including displaying the System container. You will grant rights to the System container to allow the Configuration Manager site server to publish data to Active Directory. -In the console tree, expand domain( name of your domain), and then click System. -On the Action menu, click Properties. -Click the Security tab. The System Properties dialog box displays the security permissions on the System container. Notice that the Configuration Manager site server computer (SMSServer) is not listed. -Click Add. The Select Users, Computers, or Groups dialog box appears. -Click Object Types. The Object Types dialog box appears. -Under Object types, click Computers, and then click OK. -In the Enter the object names to select field, type smsserver name and then click OK. - The Select Users, Computers, or Groups dialog box appears. Notice that the Configuration Manager site server computer is now listed with Read rights. -Under Permissions for SMSSERVER, click Full Control under Allow, and then click Advanced. The Advanced Security Settings for System dialog box appears displaying the rights for various accounts. -Under Name, click on SMS SERVER name, and then click Edit. The Permission Entry for System dialog box appears displaying the rights for SMSServer$. -In the Apply onto field, click This object and all child objects, and then click OK. The Advanced Security Settings for System dialog box appears. -Click OK. The System Properties dialog box appears. -Click OK. The Active Directory Computers and Users window appears. You can leave this window open if you want to view information that Configuration Manager publishes to Active Directory after installation. --------------------------- Logs to check Hman.log for the following information
" Active Directory DS Root:DC= Domainname here,DC=com Searching for the System Management Container. System Management container exists. Site objects existing in AD: cn=SMS-Site-Site code here. Searching for SMS-Site- Site Object. SMS-Site- exists, updating. SMS-Site-< Site Code here> successfully updated. " ---------
sitecomp.log for the following information
Publish Servers in Active Directory. DS Root:DC=SCCMSERVER,DC=DOMAINNAME ,DC=com Searching for the System Management Container. LDAP://CN=System Management,CN=System,DC=SCCMSERVER,DC=DOMAINNAME,DC=com container exists. Site System is the Default Management Point. No Fallback Status Point installed on the Site Size of Signing Certificate: 0 Signing Certificate: Checking configuration information for server: SECONDARY. SECONDARY is the Default MP. Updated MP Configuration for SECONDARY. Installing Security settings on site system ... Security settings are up to date for SECONDARY. Installing DNS publishing settings on site system ... DNS publishing settings are up to date for SECONDARY. Publishing SECONDARY(SECONDARYSERVER NAME.SCCMSERVER.DOMAINNAME.com) as a Management Point into Active Directory. SMS-MP-SECONDARY SERVER SITE CODE -SECONDARY successfully updated.