IT Management Suite Best Practices Sean Waddell Sr
IT Management Suite Best Practices Sean Waddell Sr. Product Manager Symantec Confidential 1
Discussion Goals and Agenda 1. Goals – Are we working on something of value to you? – If so, how can we improve? 2. Agenda – ‘Best practice’ project description – ITMS data communications – Hierarchy and replication – Your requirements Your Needs Gap Analysis Us Today Symantec Confidential
Best practices project • Deliver detailed best practices for planning & implementation of IT Management Suite • Provide guidance for product use by testing ‘real-world’ scenarios • Collect, prioritize, and drive features to improve scalability and centralized management Presentation Identifier Goes Here 3
General scalability recommendations Managed Endpoints Operating System SQL Version Suite Hardware Requirements Tuning & Configuration Small <500 Windows 2003 SQL 2005 Express CMS 2 Cores, 4 GB RAM Out of Box Medium <3, 000 Windows 2003 Enterprise SQL 2005 CMS 8 Cores, 8 GB RAM w/SQL 4 Cores, 4 GB RAM—NS 4 Cores, 8 GB RAM—SQL Task Interval 10 min Large <10, 000 Windows 2003 Enterprise SQL 2005 CMS 8 Cores, 8 GB RAM—NS 8 Cores, 8 GB RAM—SQL TS/PS Off Box, Agent Policy 2 hrs 8 Cores, 8 GB RAM—NS 8 Cores, 16 GB RAM—SQL Very Large >10, 000 Windows 2003 Enterprise Symantec Management Platform Architecture SQL 2005 CMS Agent App. Pool with multiple Worker Process 4
Scalability best practice needs • To make decisions, implementers and users need to know: – How many servers do I need? – What type of hardware is needed? – What is the performance impact on NS and SQL servers? – How will network performance be affected? – How much disk storage will it consume? Which is most needed? Symantec Management Platform Architecture 5
Inventory Solution data flow Symantec Management Platform Architecture 6
Patch data flow Symantec Management Platform Architecture 7
General Considerations for Hierarchy • Designed to simplify management. Not all multi-NS environments make sense to implement hierarchy • Consider hierarchy load and delay when planning implementation • Use flat (2 tier) NS hierarchy • Replication is ‘selective’ – not all data is replicated
Policy Management in a Hierarchy • Policies flow down from parent to child • Default schedule replication is 24 hours Job and Task Management in a Hierarchy • Consider quick delivery timeouts and reporting is not indicative • If collection/filter not replicated, job/task will not target any devices
Inventory & Reporting in a Hierarchy • Replicates selected data classes up to parent • Additional data classes added through replication rules Asset & Software Management in a Hierarchy • Uses inventory forwarding model similar to reporting server in NS 6 when in hierarchy
Hierarchy model
Common hierarchy requests • Better detail for tracking replication status – When completed – What replicated and did not – Troubleshooting tools Which are most important to you? • Simpler to customize replication rules – Simpler to customize which objects replicate • Bi-directional support for Asset and CMDB – Asset is actionable – CMDB custom objects replicated for audit purposes • Near real-time, complete reporting at parent NS
Thank you! • Reference – Planning and Implementation Guide, (a general guide of the Symantec Management Platform), KB article # 45803, https: //kb. altiris. com/display/1 n/article. Direct/index. asp? aid=53729&r=0. 1029474 – Symantec Management Platform Architecture and Design, (companion to P&I Guide with specific details about data communications and hierarchy capabilities), KB article # 53729, https: //kb. altiris. com/article. asp? article=53729&p=1 Presentation Identifier Goes Here 13
- Slides: 13