Microsoft lists all SMS add-ons...

Ever wanted to manage Blackberries?

 

SMS server dimensioning is a complex question because of the number of
criterias involved:

 

1. On the clients: agent scheduling is important (hardware inventory
schedule, software inventory schedule...)

2. Number of packages and distribution frequency.

3. Are you planning to use ITMU for patch management?

4. And, the "classical" stuff: number of clients, available bandwidth, SQL
performance...

 

This being said, here is my advice:

 

1. Use SQL 2005.
2. You might want to keep the SQL db on the Site Server. Having SQL on a
different server is only recommended in the largest sites.
3. Yes, right, use (multiple) dedicated DPs.
4. For MP, NLB is supported. in a typical scenario, one single MP on site server
should be enough. If needed, you can always scale out later using NLB.
5. SQL on SAN will deliver a huge perf boost.
6. I am not sure Windows server can truly use 8 gigs (depends on Windows
Server version?)
7. Make sure you understand how to use SMS SQL scheduled tasks to keep your
SQL db optimized.

For the server:

For the client:

Another FAQ: which accounts are used by SMS during Software Installation?

Well, the answer lies in this little TechNet magazine article:

There is only one way of understanding the "obsolete" bit:

 

This nice article details which products are covered by ITMU and which ones are not.

This is a FAQ in the SMS courses I deliver.

DCM is a tool for ensuring systems in the enterprise adhere to key configuration requirements (template, baseline...) It looks very flexible.   the current release allows full access to check settings in WMI, the file system, the registry, the IIS metabase and Active Directory.

More info:

 

Wow, I am just about finished with a very successful large-scale (4000+ clients) SMS 2003 project, from Design to Operations. Here are some of the challenges we met:

 

6. How will you integrate the SMS inventories with the current inventories (typically some Access db) used by the support staff today? You might have to consolidate some information in the SMS db. Using a reporting site is definitely recommended.

 

5. The best method to deploy your SMS clients is the "Push Installation". All other methods rely on features that I did not want to change/control (logon script, group policies...). The Push Installation, in combination with the AD Discovery, allowed me to silently install 4000+ clients in a few days.

 

4. A good design is a simple design. That's right, SMS 2003 is scalable enough so that one single site should be sufficient in most scenarios. Multiple (secondary) sites design ...mmm, well... no thank you - unless you have a VERY good reason (and no, bandwidth is not a good reason, see my previous posts).

 

3. Hotfix deployment works well with SMS ITMU, the challenge here is not a technical one, but rather an organizational one. We must follow a well thought plan, including interaction with users. Say the magic word "ITIL" to the change and configuration manager... 

 

2. User communication is critical. Should they turn off their laptops? Maintenance Window? Forced reboots? Make sure your strategy includes a communication plan to users (including managers, yes...) 

 

1. Active Directory & DNS must be...perfect! Get rid of these stale AD accounts, not up-to-date DNS Reverse Lookup Zones BEFORE you start playing with SMS.

 

On to another SMS project,

Cheers,

 

MV

During the last few SMS 2003 official courses, many expressed their interest for the BDD.

If we have enough demand, we will organize a special one-day seminar on this subject.

If you are interested, leave me a note on this post.

 

Thank you,

Cheers,

 

MV

Well, this is a FAQ by our clients during the SMS course. The basic scenario is that the network infrastructure is a highly distributed one: your network features many remote clients linked by slow and unreliable WAN lines. And, of course, you planned for at least one SMS Distibution Point in each location across the WAN links.

How does SMS 2003 SP1 manage traffic from the packages source share to the DP? Two scenarios are possible:

 

1. Inter-site traffic from the packages source share to the DP is "managed" by SMS Senders (compression and scheduling). This is one of the reasons you would create an SMS hierachy with child sites. But...hey...we don't create a new SMS Site for these 10 clients across the WAN.

2. Intra-site traffic from the packages source share to the DP is unmanaged. As far as I know, there is no SMS built-in tool that would allow you schedule and/or compress this kind of traffic.

 

So, what can we do? Here are a couple of suggestions "from the trenches":

 

1. Use DVDs, copy sources on them and send them by post to your WAN location. Copy on the DP share. Yes, I know, you don't like that, but hey how do you get the Visual Studio 2005 Full package across a 64 Kbs line?

2. Carefully schedule the DP update, possibly using scripts. I haven' tested this, but it should allow me to send the package to the DP at 02:00 AM, when the backups are finished...

3. Do they REALLY need Visual Studio 2005 over there?

4. Use a 3rd party tool like 1e's SMS Nomad Branch. this tool will allow you to "manage" the traffic from the packages source share to the DP. We are testing it right now and I must say it looks impressive. This might be just what you are looking for. See www.1e.com.

 

Cheers

 

MV

And I am currently downloading it. We'll test it asap. I am so curious to what they changed. Msoft promised a better and simpler UI . We'll see. Cheers. MV

We all love using Excel... so why not use it for SMS reporting?

This nice ITForum article will tell you how:

Cheers

MV

These FAQs help  me a lot when delivering the 2596 course. Check it out!

Client FAQ:

Server FAQ:

Cheers

MV

Well, SMS creates quite a few users and groups upon installation.

Here is a comprehensive list of them and their role:

Cheers

MV

I did not think it was possible, but apparently some people tried it...

SMS 2003 does not load balance multiple Management Points by itself. One must configure Network Load Balancing. This MyITForum entry has a nice how-to.

Re-sending a SMS Package/Program to SMS 2003 clients is more tricky than you think.

the answer lies in this KB article.

Cheers.

These guys run a forum that features SMS Q&As that seem interesting:

This error occurs because the SMS computer account (if you are running Advanced security) or the SMS Service account (if running in Standard security) does not hyave the appropriate permissions on the the System, System Management container.

 

Please review KB 830022.

 

Please note that if using AD Users and Computers, one MUST use the Delegation Wizard. Simply giving Full Control on the System Management Container does not give the appropriate permissions on the created child objects. Let's use the Delegation Wizard...