- When you configure your Software Update Point, it is recommended to only select the appropriate product in the list… otherwise you will blow off your DB.
- When you install WSUS, it is recommended to install only the wsus sdk rather then Wsus through server manager.
- Microsoft recommended as a Best pratice to not select any product and classification when you configure the initial synch from SUP, because Wsus as it own catalog and it is not up to date. So configure the product and classification later in the properties.
- Client settings are now collection vs site wide in configmgr in 2007, so you can have multiple Software updates policies settings within the same site based on collections.
- No more template wizard, you must configure software update group and save settings has a template (note that you can cancel the wizard, so this only create a template).
- Default value for software update max run time is now set to 5 minutes.
- Deadline settings override non business hours define by the users (define in software center).
- In Sccm 2012 Internet-based users now point to a MP into the DMZ to get the policies for the updates (mandatory and deadline) but now download content from windows update, so there are no requirement for a DP in the DMZ.
- Software update Automatic deployment Rule (ADR), give us the ability to schedule the download of the update, update our DP, configure our deployment settings, and push the updates to the client based on filtering.
- Wsus has nothing to do with the content, is only use for scan source.
- Software updates groups (which is replacing the updates list) has now a limit of 1000 vs 500 in configmgr 2007.
- Large Software updates deployment are not recommended, it’s better to use multiple smaller deployment, because largest deployment impact client side(during the evaluation, which happen in the memory) and on the server side (which have to summarize every cross-deployment between client to get the client state (compliant, non compliance, unknow, etc).
- Updates list can be migrated to updates groups.
- Softwre update group can be use for compliance and for deployment . Also, try to not modified the software update group, because each single change force all client to check again for compliance.
- If you are using ADR for patch thuesday, you must configure the properties to check the updates released or revised in the last DAY ONLY.
- you can use search criteria title to eliminate some of the product you dont care about, ex; -“titanium”
- when you are deploying definition (no reboot are required) updates you can set the level of state message at low, so this will eliminate all the msg for the troubleshooting about the state, like progression.
- it is recommended to set your synchronisation 2 hours before the evalutation of the rule.
- Let the process happen every month, so when the updates will be expipred, the will clean up automatically and also if a client his offline for 10 month. He will received all the deployment and only required 1 reboot.
- no reason to merge multiple monthly groups in the same group.
- expired updates are automatically removed (content + metadata) from the DP except for the updates in a active deployment, but superseeded updates not. We can choose.
Best Practice Recap;
- Create Update groups of all required release updates for compliance report (do not exceed 1000)
- Use migration from confmgr 2007 or create new update groups for require release updates
- Delegated admins can create deployments of any approved update group
- Create new group for each patch tuesday (manualy or with ADR)
- Update groups can be used to measure compliance not deployed
- add monthly updates tp the compliance update group each month for overall compliance
- client optimized to evaluate multiple updates deployments with applicable updates
- cleanup expired updates acroos your group through search