July 2008 - Posts
Last week, a few of us got together in Seattle for the evening. Here are a few pictures from the night and my trip to Mount Rainier the next day.
Seattle from Kerry Park on Queen Anne Hill:
(From left to right: Brian Mason, Greg Ramsey, Yves Robitaille, and me)
There are pedestrian walkways all over Seattle and the surrounding area. I thought this was quite inventive and effective as I watched someone cross in front of me carrying one of these flags.
Some shots at Mount Rainier:
Too bad it was cloudy. Here is the view from Sunrise of the peak. I was about 6100 feet up the mountain.
It was scary driving up the mountain, there wasn't much to keep you on the road. Those trees on the right were 30-40 feet tall.
I love taking time-lapse photos of water. This was a spring running down the mountain just off one of the roads.
Click on the thumbnails to see larger images. Please note, all images are copyrighted.
It seems that this discussion comes up quite often on whether to install the ConfigMgr database on the same server or on a separate server. While there are camps that side one way or the other, I thought I would throw my hat in on this topic.
Generally speaking, both installation are OK. (GASP :o) Before you throw me off a cliff, hear me out.
Installing the site database on the computer on which the primary site is installed generally results in good site performance if adequate hardware is used. However, because Configuration Manager is more database processing intensive than previous versions of SMS, if there is a high speed connection between the site server computer and a remote SQL Server computer used to host the site database, site performance might be better than when the database in hosted on the same primary site server.
This is because in a single server installation performing large amounts of data processing, it can be expected that SQL processes will normally utilize about two-thirds of the processing of the system, leaving the rest of the resources to be divvied up between SMS Executive and the rest of the OS and software. This can result in degraded performance and slow responses.
Using a remote SQL Server to host the site database, with a fast network connection to the site server, allows two computers to more effectively process site information by working in parallel. For data processing intensive sites, this configuration results in less resource contention than using a single computer to host both the site and site database server installations. With that said, there will undoubtedly be trade-offs in network traffic.
In a case were there are about 10,000 clients and the data process is frequent, if there is a fast network connection between the SQL server and the SCCM server, I would recommend that using a remote SQL server. For more information, please view the articles below:
Performance Considerations When Designing Configuration Manager Sites
http://technet.microsoft.com/en-us/library/bb932210(TechNet.10).aspx
Configuring Configuration Manager Sites for Best Performance
http://technet.microsoft.com/en-us/library/bb892809(TechNet.10).aspx
Performance Configuration Recommendations
http://technet.microsoft.com/en-us/library/bb932186(TechNet.10).aspx
Best Practices for Central and Primary Site Hardware and Software Configuration
http://technet.microsoft.com/en-us/library/bb932180(TechNet.10).aspx
I came across this feed entry and thought it was humorous that even with all the technological benefits of Vista, the steps are vaguely familiar.
http://windowshelp.microsoft.com/Windows/en-US/help/83EC0FFE-EE04-4D53-8B87-25D1F05C954E1033.mspx
There is no magic bullet, and one of the suggestions is even rebooting - something that I thought Vista was supposed to help with. Odd that all of the suggestions are the same as if running XP. I guess a Windows OS is the same, no matter what skin it runs:)
Now I am bashing a bit on Vista, but for the most part it is good. I have my issues with it, and go through my "I want to wipe and install XP" rant every other week or so. Actually, as I write this and contemplate, I can't think of anything I use during my day to day work that Vista does better or helps me with.
I have issues mapping network drives with alternate credentials, getting Vista to recognize that an offline resource is online and forcing it to use the live copy and not the cached offline copy. Networking in hotels is horrible. I have gotten so frustrated that I have just given up and resorted to surfing and mail through my phone instead of my laptop. Also, half of the time I have issues with the display setting when connecting to projectors and it is hit or miss whether it extends properly and sets a correct screen resolution, let alone detect that there is even a projector connected.
O well, enough ranting... I have to reboot :)
One of the questions that I often get surrounds how to manage Software Updates in Configuration Manager. I could just tell you what to do, but I think it is better to explain how the process works and give then give you recommendations on how to manage your updates. This enables you to understand why I make the recommendation and also may prevent you from reinventing the wheel and wasting your valuable time.
In Parts 1 and 2, I will cover how Updates Deployment works and how the WSUS deployment processes were molded to fit within ConfigMgr processes. This won't be a highly technical discussion, but more of process flows and overviews.
First, it might be good to understand that while update deployment is using the Configuration Manager framework for deployment, the process is built upon WSUS so it doesn't meld directly. That is because ConfigMgr deployments are push methods, while Windows Updates are pull methods.
Let me explain: With Windows Update, the client "pulls" just the updates from WSUS based on a catalog of available updates. WSUS provides a list and the client scans and then requests just what it needs from the list. The service then executes commands based on the update catalog information.
With ConfigMgr or SMS, the deployment is built and targeted to a system or group of systems. When the system recognizes they have a deployment to run, they execute it based on the deployment criteria whether they need it or not. As long as the target system meets the requirements, the program is run.
So to sum it up, WSUS is all friendly and says "Come look what I have and take what you like", while ConfigMgr says "This is what I have and your gonna take it, whether you like it or not". I guess that makes ConfigMgr a bit heavy-handed sounding. So how does WSUS's soft approach fit into the heavy-handed design? Well, in Part 2, I will cover the distribution flow for deployments and how WSUS processes have to be tailored to fit within that.
In my consulting, one of the questions that I often get surrounds how to manage Software Updates in Configuration Manager. While I could just tell the client the steps to perform, I find it better to use the opportunity to mentor them in deployment concepts and enable them to make better decisions in the future.
In this three-part series, I could just tell you what to do, but I think it is better to explain how the process works and then give you recommendations on how to manage your updates. This enables you to understand why I make the recommendation and also may prevent you from reinventing the wheel and wasting your valuable time.
In Part 1 and 2 of this series, I will cover how Updates Deployment works and how the WSUS deployment processes were molded to fit within ConfigMgr processes. This won't be a highly technical discussion, but more of process flows and overviews. In Part 3, I will discuss how to utilize what we have learned to help build update deployments that are easy to manage and successfully keep your clients updated. In Part 4, I will discuss how to manage your updates for the long haul.