This blog is to keep aware of the general points in SMS/SCCM which have been come around.
Important Teems used in Software update point process:
Deployment : An object that is used to deploy software updates to clients in the target collection.Deployment objects are replicated to child sites where they are read only.
deployment package: An object that hosts software update source files.Deployment objects are replicated to child sites where they are read only.
Deployment template: A template that stores many of the deployment properties that might not change from deployment to deployment and that are used to save time and ensure consistency when you create deployments.
Network Access Protection: A policy refreshment platform that allows you to better protect network assets by enforcing compliance with system health requirement.configuration manager 2007 NAP lets you include software updates in your health requirements.
search folder: A folder that provides an easy way to retrieve a set of software updates that meet the defined search criteria.
software update: Composed of two main parts: The metadata and software update file.The metadata is the information about each software update and is stored in site server database.The software update file is what client computers download and run to install the software update.
software update file: The file that the client computer downloads ,such as an executable(.exe) or windows installer (.msi) file,and then installs to update a component or application.
software update metadata: Data that provides the information about software update, such as name,description,products that the update supports,update classification,article ID,download URL,applicability rules and so on.
Update list: A fixed set of software updates that can be used for delegated administration and creating software update deployments.There are also several reports that provide information about update list.
What is RDC in SCCM ? and why do we use this component as Prereq ?
1) Configuration manager always compresses the data when that data needs to be sent across sites. For instance if you have a site hierarchy and you create the package on Site 1 and distribute it to a distribution point belonging to the child site we will compress the package on the source site and send it down to the child site. This always happens by default.
2) Remote differential compression is used to smartly compute delta content that needs to be transferred to a DP. Basically if some content already exists on a distribution point and you want to send some updated content then we use RDC to compute only the delta that needs to be sent and thus use network bandwidth effectively.
All of the above applies to the server side.
Once content is staged on a distribution point clients download it using BITS/SMB (depending on whether your distribution point is BITS enabled or not). In this case there is no compression - clients download each individual file from the distribution point as is. One of the exceptions is Branch Distribution Points (which are hosted on client machines) which also use RDC to do smarter download of delta content.
What SysPrep does :
the computer should be in workgroup because of Unique SID and other unique
ID's.If the computer is in domain (mean duplicating the SID's) and if you try to capture it (sysrep will try to join the computer to workgroup) and deploy ,the destination computers will have the same GUID.Sysprep assigns a unique security ID (SID) to each destination computer the first time the computer is restarted. For more informaiton on sysprep read here.
sysprep Not only remove SID, it also provides the following functions:
- Removes the computer name; whereas a unique SID might not be required in some environments, unique computer names are certainly essential
- Removes the computer from the Windows domain; this is necessary because the computer has to be added to Active Directory with its new name
- Uninstalls plug and play device drivers, which reduces the risk of hardware compatibility problems; required drivers will be installed automatically on the target machines
- Can remove event logs (reseal parameter); this is useful if you have to troubleshoot a target machine
- Deletes restore points; if you have to use system restore on the target machine, you could run into problems if you use a restore point from the master PC
- Removes the local administrator's profile and disables the account; this ensures that you don't accidentally copy your files to the target machines and leave the admin account unprotected
- Ensures that the target computer boots to Audit mode, allowing you to install third-party applications and device drivers
- Ensures that mini-setup starts after booting up the first time, allowing you to configure the target computer's new name and other configurations
- Allows you to reset the grace period for Windows product activation (rearm) up to three times; this gives you more time to activate target computers.
Below listing are some of the Pro’s and Con’s of SCCM Sites Primary /secondary) configuration :
So the Pro’s are:
- Secondary sites do not require additional Configuration Manager 2007 server licenses.
- Secondary sites do not require an additional SQL Server database at the secondary site.
- Clients can be managed across a slow network connection link, such as a wide area network (WAN) connection between sites, without the need to configure client agent settings.
- Secondary sites can have management points (called proxy management points) to help prevent client reporting information, such as inventory reports and status messages, from traversing slow network connections to the primary site.
- Remote sites can be managed centrally from a parent primary site without the need for an on-site administrator at the secondary site.
Cons:
- Parent sites for secondary sites cannot be changed without uninstalling them and installing a new secondary site.
- Secondary sites cannot be upgraded to primary sites. To replace a secondary site with a primary site, you must uninstall the secondary site and install a primary site.
- Because Configuration Manager clients are always assigned to primary sites, client agent settings cannot be configured differently from the secondary site’s parent site for clients located within the boundaries of secondary sites.
Pro’s:
- Reduces site hierarchy complexity.
- Allows package to be copied out of band to a distribution point within the site.
- Does not require a server operating system. (limited to 10 connections)
- Provides on-demand package distribution, in which packages are downloaded to the branch distribution point only when specifically requested by a client computer.
- Branch distribution points download content from standard distribution points using BITS (Background Intelligent Transfer Service).
- Supports all packages, including software update packages and operating system deployment packages.
Cons :
- Does not manage traffic uploaded from clients to management points.
- Does not manage traffic when downloading policies from management points to clients.
- Does not provide a local software update point to scan for software updates.
- Does not provide precise time and bandwidth controls between sites, as a Sender does.
- Restricts available connections to 10 or fewer if using a client operating system.
When choosing between primary sites, secondary sites, and branch distribution points, you should consider the amount of network traffic that the planned and future site clients will generate. It might be beneficial to install a secondary site if the amount of network traffic generated by clients across a slow link would be greater than the site-to-site communication traffic generated by a secondary site. Clients generate uncompressed network traffic when they request policies and send information—such as inventory, discovery, and status message information—to their management point based on the policy polling interval and client agents settings you define in the primary site’s Configuration Manager console. Site-to-site communication between primary and secondary sites is compressed and can be scheduled and throttled by configuring site address settings. For more info look at here
Brief Information about How Hardware Inventory is processed when client sends to MP to process it:
When the client runs the hinv agent, it starts and sends the inventory information(can be found in inventory.log in c:\windows\system32\ccm\logs folder) to the MP server which can be found in hinv.log file.You can identify this based on the GUID or computer name. Once you see it has sent inventory information to the MP successfully, there is no problem with the client.
Next Look into the MP_Hinv log which is present on your MP server (D:\SMS_CCM\Logs ,this contains MP_DDR (full DDR for clients),MP_SINV,MP_location etc ) .You can see that, it has been processed .xml file( like Hinv Sax: loading D:\SMS\mp\outboxes\hinv.box\HinvAttachmentADDITX5X.xml).
Once MP receives the file, the file is moved from the MP outbox to authenticated dataldr.box and that the file name changes. this information can be found in mpfdm.log.
Finally open dataldr.log, Notice that the file is moved into the dataldr.box\process directory and then it is renamed to X??????????.mif
some more information from dataldr.log
Processing Inventory for Machine: XPCLIENT01 Version 1.8 Generated: 09/24/2010 12:51:34
Begin transaction: Machine=XPCLIENT01(GUID:5054FAE8-C9EB-4CEE-8C0D-1E742BA7C93A)
Commit transaction: Machine=XPCLIENT01(GUID:5054FAE8-C9EB-4CEE-8C0D-1E742BA7C93A)
Done: Machine=XPCLIENT01(GUID:5054FAE8-C9EB-4CEE-8C0D-1E742BA7C93A) code=0 (8 stored procs in XH6S6I9DX.MIF)
No more machine MIFs to be processed, terminating thread
If you see any mif files in inboxes\dataldr.box\badmifs,there is something wrong with the client information while processing to Database.
to see the inventory xml files sent to MP from client ,You can create a file called archive_reports.sms and place that in the ccm\inventory\temp folder. This will ensure that xml files are not deleted after being seng send to the management point.
Here are some of the points which i have been observed with the logs:
- In SCCM, the client component settings will be saved in D:\SMS\inboxes\clicfg.src inbox folder which will be replicated to CAP_Sitecode\clicomp folder .If you look into this folder can see, remctrl.cfg, hinv.cfg,sinv.cfg and other settings information. This client component settings will be saved in sms\inboxes\clifiles.src\clcmpdir.ini file.so inboxmgr.log file will keep the information about if there are changes in clifiles\hinv\ folder. Just tried copying new test document. In few sec ,it has been copied to CAP_P04\clifiles.box\hinv .So every 5 sec ,inboxmgr.log will logs the information about if there are any changes in hinv folder.
- When you enable the client agent settings, these will saved in clicfg.src inbox folder and command line for these settings will be under D:\SMS\inboxes\clicomp.src .for ex: hinv ,the command line used is CommandLine=i386\inhinv32.exe /s
- When the client sends its hinv to the MP, it goes to SMS\MP\Outboxes\hinv ,once it is processed there ,it will be moved to sms\inboxes\auth\dataldr.box\ folder ,it site server has any issues in updating this data In SMS DB, it starts giving alerts under component status.
About Site control file:
Configuration data is gathered from default settings installed with SMS, changes made by SMS administrators who make site configuration changes, and changes made by SMS service and thread components. When site configuration changes are made, SMS updates the site control file and the registry where configuration changes are stored.
Since most SMS services function on a schedule, after an administrator or SMS turns on a service or thread component, the component checks the site control file for its configuration. This file was created based on the original settings during the SMS site installation. SITECTRL.CT0 contains the current settings for the Site Properties which is duplicated in the SMS SQL database.
The information contained in the SMS SQL database is the information viewed in the SMS Administrator Site Properties. The SMS Administrator queries the SQL database for the information. Whenever you make a change in the SMS Administrator to the Site Properties the SMS Hierarchy Manager service creates a temporary configuration file in the SMS\SITE.SRV\SITECFG.BOX directory with a CT1 extension.
This file contains the new configuration based on the selections you have picked. When the SMS Site Configuration Manager service scans this directory and sees a *.CT1 file, it picks the file up and overwrites the SITECTRL.CT0 file with the new configuration. Then it creates a *.CT2 file that is picked up by the SMS Hierarchy Manager service which updates the SMS SQL database with the new information.
The CT1 file is generally considered the PROPOSED file and the CT2 file is considered the ACTUAL Site Control files. These files are deleted once the property change process is complete. The CT0 file is the Master Site Control file. Logically
1. SMS_HIERARCHY_MANAGER creates the CT1 file.
2. SMS_SITE_CONFIG_MANAGER overwrites the CT0 file, deletes the CT1 file, and creates the CT2 file.
3. SMS_HIERARCY_MANAGER updates the SMS SQL database with the CT2 file and deletes it.
site control file gives you SMS site hierarchy properties like site server name ,site code,site name ,if there are any odd an packs(like OSD,Mobile device ,version, security mode
It contains the properties of all component manager like SMS_Discovery_data_manager,SMS_site_Hierarchy_manager etc with description of SMS ID’s like 10007,10009 etc)
About SMS Provider:
The SMS Provider is a WMI provider that allows both read and write access to the Configuration Manager 2007 site database. The SMS Provider is used by the Configuration Manager console, Resource Explorer, tools, and custom scripts used by Configuration Manager 2007 administrators to access site information stored in the site database. The SMS Provider also helps ensure that Configuration Manager 2007 object security is enforced by only returning site information that the user account running the Configuration Manager console is authorized to view.
The SMS Provider can be installed on the site database server computer, site server computer or another server class third computer during Configuration Manager 2007 Setup. After setup has completed, the current installed location of the SMS Provider is displayed on the site properties general tab.
If the SMS Provider computer is offline, all Configuration Manager 2007 consoles for the site will not function.
Delete Aged Discovery Data:
Delete aged discovery will delete any client for which it hasn’t received any ddr within the configured timeframe regardless of what discovery method generated the DDR.
Delete inactive client discovery data:
Delete inactive client discovery data will delete any clients marked as inactive for the period configured. Clients can become marked as inactive for 2 reasons.
1) The client is marked as obsolete
2) By the client status reporting feature in ConfigMgr 2007 R2. If you haven’t implemented this clients only become inactive when they are obsolete.
This task isn’t just looking at heartbeat ddr’s as you stated, it looks at the inactive bit set or not. Now the lack of a heartbeat discovery ddr is one of the things that could mark a client inactive if you implemented the client status reporting feature, as could the lack of software and hardware inventory or the lack of requests to a management point for a machine policy.
Delete obsolete client discovery data:
Delete obsolete client discovery data works similar to delete inactive but works on the obsolete bit as opposed to the inactive bit.
Clients are marked obsolete if they are determined to be a new record for an already existing client, and the records can’t be merged.
So as I stated in the beginning running AD system group discovery has no impact on clients being marked active or obsolete and hence will not influence their corresponding maintenance tasks.
Some more info about When client becomes Obsolete or Inactive etc:
- Resources are only marked Obsolete if another resource is created with the same HW ID
- A resource deleted by the Delete Aged Discovery Data task will be recreated by AD Discovery if the object still exists in AD.
- A resource will be marked Inactive it it is marked obsolete (this usually doesn't matter though because the delete obsolete time is usually less than the delete inactive time)
- A resource will be only marked Inactive by R2 client health, if it is newly discovered, or is obsolete. Looking back at previous answers of my own (on this and other forums), I've stated that a lack of heartbeat will also cause a resource to be marked inactive. Based upon the documentation which I've just reviewed, I don't think that this is true.
Difference Between Refresh DP and Update DP :
1) Update distribution points increments the package version, goes to the source location, constructs new package content but only sends the delta between what is already present on the DP and what is currently in the new package source. Also this action is package specific and once you trigger this action all the DPs to which the package has been distributed will get the new version.
2) Refresh distribution points does not increment the package version but simply sends out the current version of the package content again to a specific DP. So this is action is specific to a package-DP assocation and should be used when the content on any particular DP appears corrupted.
Impact of enabling BDR:
1) For Update Distribution Points: Consider the scenario where one (or potentially several) files in the package source has been updated/modified. Enabling BDR would trigger distribution manager to do a diff between the current version of the file and the new version of the file and only send the delta changes within the file. On the receiving side we will then perform a BDR merge for that delta. So in the BDR case we may end up sending lesser data than in the scenario where BDR is not enabled on the package.
2) For Refresh Distribution Points: BDR setting has no affect - we simply send the entire current version of the package
Why to target computers instead of users when deploying applications with sccm:
Managabilty disadvantages of targetting users:
• When you target users for software deployments you will lose the manageability of your environment there you link the advertisement to the logon of the users onto a computer within the Active Directory domain. Those users can log on/off wherever they want and therefore software gets installed on computers where this software wasn’t supposed to be available. This also makes this software also available for other users who shouldn’t have access to that specific software package.
• From time to time it is necessary that administrators or helpdesk operators take control of a users machine, this machine will be targeted for distribution of software intended for the Administrator / helpdesk operator.
• There these users can log on to any desktop you will have no idea on where your software will get installed thus you don’t have any idea of how many software licenses for a specific product are used or how many times this software is unnecessarily installed.
• Users will need to log off and log on again before the machine with the current user will be added to the correct collection to get its software advertised. When software is mandatory, a new logoff/logon is required to get it installed (due to the security token only being created at the time of log on to the machine).
• When you target computers you will have less work there SCCM is primarily designed for this way of software distribution. This means less IT-costs and thus saving your company money in the long run.
Technical disadvantages of targeting users:
• There more software will get installed on the different clients in your environment because you can’t control these installations anymore; a larger overhead will be created on your network infrastructure. Some software packages are very large so this can have a real impact on the performance of the corporate network.
• Although SCCM can target users and user groups; software distribution history on the local client is part of a different area in WMI and the right-click tools, SMSClient Center, and lots of other wonderful SCCM utilities either don't interface with that user-specific WMI area at all, or are inconsistent. Targeting users instead of computers will thus limit you in the use of your SCCM environment.
Conclusion:
Although targeting of users and user groups with SCCM is supported, it is strongly advised to NOT use this feature of SCCM!
Depreciated Tools in Win PE Version 2.0:
Intlcfg.exe
Peimg.exe
Pkgmgr.exe
PostReflect.exe
VSP1CLN.exe
Update the registry changes to the computer without restart or log off and log in:
When you do any registry changes,you may need to log off and log in to apply these changes to the computer .Instead you can run the following command without log off.
You will have to run this command as Administrator (of course the computer will not allow to change any registry changes if you are normal user)
RUNDLL32.EXE user32.dll,UpdatePerUserSystemParameters ,1
How to Clone a VDI/VHD File if you receive an Error when Using the used VDI File:
Today,i have created a VDI file using Virtual Box with Server 2008 Operating System ,this can be used for all my Lab purposes.So using the existing one,i made a DC and next is to create SCCM.So started creating New VM for SCCM using Existing VDI but it doesnt work out since,the UUID is already in use with domain error is like similar to below one “cannot register the hard disk with UUID in Virtual Box”.
This case is not like in Virtual PC,since you can use the same VHD as many times as you like.
So to resolve this,you will need to clone the VDI with Vbox manage tool which comes along with Virtual Box,You dont need to download it again.
Open the CMD prompt and change the directory to C:\Program Files\Oracle\VirtualBox
Now type vboxmanage clonehd “E:\Lab\SCCM R2\SCCM.vdi” “E:\Lab\SCCM R2\SCCMR2.vdi”
Where SCCM.vdi is My Exisitng VDI and SCCMR2 is My new VDI file.
VBscript Tips:
VB Script Command to pipe the data to file:
How to append data to files in VB script:
Set fso=createobject(“scripting.filesystemobject”)
Set objtextfile=fso.opentextfile(“eskon.txt” ,2 ,true)
’2 is for Writing the data and 1 is Read and 8 is to append data
Objtextfile.writeline(“This is simple file” & thisisavariable)
Open Text File Method (How to Read the Text file to read all the computer information):
set fso=createobject(“scripting.filesystemObject”)
Set objinputfile=fso.opentextfile(“eskon.txt”,1, true)
do while objinputfile.AtEndOfline <> then
strcomputer-objinputfile.Readline
<do something here>
Loop
Below is the Example for listing the disk space avilable with Parition names for given list of computer in text file:
Set fso=CreateObject(“scripting.filesystemobject”)
Set objinputfile=fso.OpenTextFile(“eswar.txt”,1,true)
Set objoutputfile=fso.OpenTextFile(“raju.txt”,2,true)
Const HARD_DISK = 3
Do While objinputfile.AtEndOfLine <> True
strcomputer=objinputfile.ReadLine
Set objWMIService = GetObject(“winmgmts:\\” & strComputer)
Set colDisks = objWMIService.ExecQuery _
(“Select * from Win32_LogicalDisk Where DriveType = ” & HARD_DISK & “”)
objoutputfile.WriteLine (strcomputer)
For Each objDisk in colDisks
objoutputfile.WriteLine(“DeviceID: “& vbTab & objDisk.DeviceID)
objoutputfile.WriteLine(“Free Disk Space: “& vbTab & objDisk.FreeSpace)
Next
Loop
Sending an Email with list of information from the script output commands:
Set objEmail=createobject(“CDO.Message”)
objEmail.From=eskon@eskonr.com
objemail.To=eskon@eskonr.com
objEmail.Subject=”info about script output!”
objEmail.Textbody=objoutputfile.Readall
objEmail.configuration.fields.Item(“http://schemas.microsoft.com/cdo/configuration/sendusing”)=2
objEmail.configuration.fields.item(“http://schemas.microsoft.com/cdo/configuration/smtpserver”)=”ch.eskonr.com”
objEmail.configuration.fields.item(“http://schemas.microsoft.com/cdo/configuration/smtpserverport”)=25
objemail.configuration.fields.update
objemail.send
