I have had customers want to manage device drivers easily and while the built in task sequence for applying drivers allows you to specify a condition and then install a specific category of drivers or all drivers from a package (http://blogs.technet.com/b/deploymentguys/archive/2008/02/15/driver-management-part-1-configuration-manager.aspx), I like looking at a simple task sequence without 20 tasks for installing devices.
If you have MDT integrated, you can add a gather sequence and add the following information that will override the “choose from categories” values for that specific model. It would mean you would need to add the drivers to a category for that model though. I found the powershell from Michael Niehaus on importing drivers into SCCM and finding duplicates worked wonders for helping to manage drivers in ConfigMgr (http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-2.aspx). I can now just place any extracted drivers into a directory structure matching the category naming and it imports and updates drivers easily for me.
Anyways, if you add "Priority=Model,Default" to you customsettings.xml and then add a section for your model as returned from a gather task (can be found in your bdd.log) you can specify the drivers you want. The following is an example for a file that would support Lenovo and Dell. The assigning of models can also be done with MDT DB integration, but if you only have a few models you are concerned with, you can just specify them here. Also, if you need a specific app based on model installed you can add the task to install software and specify "Install Multiple applications" and use PACKAGES as the base variable name. Then just add the PACKAGES001(002,003,etc…) with a package id and program name to run it.
It helps me keep my task sequences from being so huge with tons of model checking since I like to be anal about specifying drivers and apps per model.
[Settings]
Priority=Model,Default
Properties=OSDAutoApplyDriverCategoryList
….
[766945U]
;Lenovo X61
OSDAutoApplyDriverCategoryList=DriverCategories:f4bc60c1-74d8-4708-aae0-7d30a0f2d0d2,DriverCategories:d450655d-fcb5-4059-8554-15ff4b1d1c47
PACKAGES001=CLE00000:OSD Install Fingerprint Software
[OptiPlex 330]
;Dell OptiPlex 330
OSDAutoApplyDriverCategoryList=DriverCategories:d450655d-fcb5-4059-8554-15ff4b1d1c47
Now you might ask how I get the DriverCategories:<GUID> value that I use in the section. While there are some neat scripts you can find and run, I’m lazy and just created a blank task sequence with a install drivers task pointing to the specific category I want. I export the task sequence and open the XML and the information is there for me. I can even build that task sequence out for all my models (minus the WMI query conditioning) and then export and use a little Find and Replace to reformat the file to paste into my customsettings.ini directly.
Actually I love using the customsettings file and defining variable in it that manage sections of my task sequences. It enables me to turn on and off groups/tasks in the task sequence without going in and editing it directly. I just set a condition at a group to look for the variable to not be set to true (or something like it). It will run the group of tasks if the variable doesn’t exist or is set to something else (say false). This allows me to disable a group tasks in production as I work on testing it (using a duplicate task sequence) and then just publish the updated custom settings file to make it live in production once it works as expected.
Like I said in my blog post before, make sure you are treating the problem and not the symptom. Also, I said I was going to go back and rebuild to see if my experiences were really a problem or whether they were just a symptom. It really didn’t take me this long to rebuild, but I was working on another server for my lab and was running into problems again with the base VM VHD I had just created and had used for my lab ConfigMgr server. I was seeing similar errors as the ConfigMgr server as in normal stuff needing slight tweaks, as well as odd errors in the eventlog for things that should be working like normal. After researching a VSS error I was having, I decided it was more likely the file system was somehow corrupt, even though disk scans came back fine.
I assume this was because I had just built over top an existing VHD, only wiping the partition and installing new ones. There must have been a corruption in the VHD because when I started the TMG server build with a new fresh VHD file, everything flew by and worked as expected. With that success I was pretty sure my experience on my new ConfigMgr server were symptoms of the bad VHD and not problems within themselves. I went back to my ConfigMgr server, backed up my scripts, deleted the VHDs, and started a new VM from scratch.
Well, from starting at scratch seemed to have been the trick. I didn’t have to enable TCP/IP as a communication protocol for SQL and I got rid of the previous random errors in the eventlog. However, I still ran into the problem with the ConfigMgr setup assigning SQL to use SSL and the self-signed cert. The setup was hung again and the same spot it did before so I jumped into the eventlogs and look what I saw…
Punching in the “Certutil –store My” into the commandline, I found the matching cert
And drilling to the cert store on the computer, I found the file and checked the permissions. Again is had the unknown SID. I added the account the SQL service was running under and gave it the default read permissions.
I then went and started SQL (successfully) and the setup continued on. Good thing I had run into this before, so it only delayed me a few moments, but it still makes me wonder why it is happening and what that rogue SID is.
The following link http://support.microsoft.com/kb/243330 tells me that the SID is a unique login session. More research shows that Winlogon creates a unique logon SID for each interactive logon session. A typical use of a logon SID is in an access-control entry (ACE) that allows access for the duration of a client's logon session. For example, a Windows service can use the LogonUser function to start a new logon session. The LogonUser function returns an access token from which the service can extract the logon SID. The service can then use the SID in an ACE that allows the client's logon session to access the interactive window station and desktop. The SID for a logon session is S-1-5-5-0, and the RID is randomly generated. I am assuming my issue revolves around me using a domain account for the SQL services, therefore getting a Login Session SID and RID vs just getting the actual service account’s SID. I am not sure but I wonder why I don’t see anyone else with the problem. Are my Google Fu skills failing me?
In case you missed the news on Monday, SP1 for Office 2010 has been released. You can find the downloads here:
http://www.microsoft.com/download/en/search.aspx?q=office%202010%20service%20pack%201
During the ConfigMgr 2012 setup I ran into a problem were the installation was hung and not proceeding. Opening the log in the lower left of the progress window showed that setup was assigning a self signed cert to SQL and then was not moving on. After 30 minutes, I was pretty sure that something was wrong.
Assuming there was a problem related to previous troubleshooting attempts (other previous issues) I decided to kill setup and reboot (hoping it wouldn't break something). Upon reboot, I found that SQL would not start the database service (so much for hoping). I was getting an error about being able to open a SSL connection to the server and the following errors were found in the eventlog.
Log Name: System
Source: Schannel
Date: 6/28/2011 1:39:09 PM
Event ID: 36870
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: BALABMDT01.lab.local
Description:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10001.
Log Name: System
Source: Service Control Manager
Date: 6/28/2011 1:39:10 PM
Event ID: 7024
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: BALABMDT01.lab.local
Description:
The SQL Server (MSSQLSERVER) service terminated with service-specific error %%-2146885628.
There were a couple possible reasons for this, but since I knew I was using self-signed certs, I doubted that most of the possible troubleshooting and solutions were applicable. I did however run across a no longer available blog post (thanks Google cache) describing a problem an admin was having setting up FEP 2010. The funny thing is that another ConfigMgr admin had run across the post and had commented that he had the same problem with ConfigMgr 2012 Beta setup. Looking into his resolution, I assume the problem was because the service account running the SQL server service did not have access to read the self signed certificate.
By running "certutil -store My" at an elevated console, I found the certificate keys being used.
Opening a file browser to the store path, I found the matching items (you may have to enable viewing hidden system files).
Going into the security of the object, I found a unknown SID. Assuming there was a problem adding the correct account, I added the account used to start MSSQLSERVER and gave it the default read permissions. I then went back and started the MSSQLSERVER service with success.
So while this fixed my “symptom” preventing me from launching MSSQLSERVER, the underlying problem still remains. Why did I have to make a change at all? Since I have only ran across one other instance of this on Google, my assumption is more that there is something different (not necessarily wrong) with my lab setup or maybe a fluke with the Beta 2 installation. I will end up logging with the Beta team on this and rebuilding my server (thank goodness for snaps) with some different setups to see if I can replicate it. Wish me luck.
I was having problems getting my ConfigMgr 2010 Beta2 setup to connect to the locally installed instance of SQL. I was racking my brains trying to figure out why. It kept saying that it couldn't connect and to make sure I had a supported version of SQL and that SQL 2008 SP2 and/or SQL 2008 R2 were not supported.
This was quite aggravating for me because I knew I had SQL Server 2008 installed, added SP1, and then added CU10. With that you should end up with a version of 10.0.2799, which I confirmed.
Just before I was to log a ticket with the Beta team, at the bottom of the submission it said to grab the logs. The logs I thought, a great place to grab my supporting data for my case and show them a problem ... and then the problem glared back at me…
(the log can be found on the systemroot drive of the site server you are installing on)
"ConfigMgrSetupWizard Error: 1 : A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"
Hmm can't connect to SQL. But I knew I had disabled Windows Firewall temporarily to prevent this. It must be something else that was simple...and it was. I had come across this numerous times before but forgot since it had been well over a year since I performed a new SQL installation.
The answer is that SQL is not even listening on the network (you wouldn't think it needed to if it was a local install). All that needed done was to enable up the communications that are turned off by default with the installation:
I enabled TCP/IP and Named Pipes (You will need to restart the SQL services to get them to listen on the new communication protocols) and the installation continued successfully for me.
With a little time between engagements and some time off the road I felt it was time to rebuild my ConfigMgr portable lab I run around with. It was broken from some client troubleshooting so instead of trying to upgrade to 2012 from 2007 R2, I chose to rebuild the lab from scratch. It is a great practice lesson in remembering all those things I take for granted in an environment.
Now my Demonstration/Lab server is a single server implementation with Windows Server 2008 R2 SP1 that has the following roles installed: AD DC, DNS, DHCP, RAS, CA, WSUS, WDS, and IIS. This serves as the foundation for the core server for the environment. On this server I also have MDT 2012 Beta, WSUS 3.0 SP2, WISE Package Studio and will be installing ConfigMgr 2012. I am able to do most of my customer engagement demonstrations as well as provide a foundation for assisting them in troubleshooting and implementations in their environments. It has 2 private VLANs for PXE booting agents, one on the private VM network and one through the external physical NIC and an external mapped network for internet access and routing. This lets me use the server on an isolated network to test against real hardware or in a customers environment without a lot of special reconfiguration.
So I starting with a new Server 2008 R2 SP1 server, installed and configured the roles, installed the software and started to work on the ConfigMgr build. After installing SQL Server 2008 Enterprise, I installed SP1 and CU 10. Since I like to simulate distributed environments, I make sure to install using service accounts as if the SQL server was expected to run on a separate server/cluster. I am limited on resources in VMs that also share my daily laptop resources 
so I can’t really afford to split these out into different VMs. Checking that the SQL version was reporting correctly (10.0.2799), I proceeded with the ConfigMgr installation.
The next 2 posts cover the issues I encountered and the resolutions I found. One of them obvious, the other, not so. I think I will be doing some additional troubleshooting to reproduce the issues for the second problem (self-signed certs for SQL) to identify if there is something expected to be in place that I am missing off-hand. My rule of thumb is that I am having problems with default type installations, then my environment must have something that is expected to be a certain way and unless I have good justification for it not to be, then I need to fix it.
I have come across many customers that wrestle with this. They have made small fixes to the norm to address a “problem” when really they are treating a symptom and causing an entry point for a new problem when something new goes in. Get the environment back to an expected standard and troubleshoot from there.
Anyways, I hope the following assists you if you run into similar stopping points.
Came across an interesting situation today. I was working with a client installing an RMS POC and was having difficulty getting the agent to report to the RMS. It would install, uninstall, and all the logs looked fine, but the targeted server would alway appear offline. What was even more curious was that the RMS server itself was showing up as not connected.
While troubleshooting, I noticed in the tasks that we had some errors stating that an account being used to install the agent did not have appropriate permissions to logo. This was curious since the same account was the one I was logged in directly to the server with. One of the other admin's overheard us and thought to mention that they had the secondary logon service disabled on all of their servers.
Before jumping to that I thought I would do a search to se if this was a dependancy. I was not able to find any reletive information related to this service and RMS. Even so, I enabled the service and restarted the RMS services. Within moments the agents started reporting properly to OpsMgr and appeared properly in the console.
Not sure, but maybe this will help you.
Ohio System Center User Group hosted by Bennett Adelson.
From the Microsoft Solution Center at Bennett Adelson, we invite you to join us for the Ohio System Center User Group. This group’s focus is on the Microsoft suite of applications for managing and maintaining the infrastructure environment bundled under the System Center umbrella. This suite includes Configuration Manager (ConfigMgr), Operations Manager (OpsMgr), Virtual Machine Manager, Reporting Services, Mobile Device Manager, and Data Protection Manager. Please join us in the Microsoft Solution Center for introductions to the technology, technical deep dives, as well as advanced topics to extend and support your solutions. This is a great opportunity to join with your peers in the Ohio area and learn from the presenter and each other.
November Meeting
In our initial group meeting before the close of the 2008 year, we will introduce you to the System Center Suite, discuss the group direction, and take a deep dive look into System Center Configuration Manager 2007. Jason Condo from Bennett Adelson will be presenting this forum. For those of you not familiar with this product, it is the next revision of Microsoft System Management Server (SMS) which enables your infrastructure teams to deploy operating systems, software, and updates to servers and workstations, as well as provide management, reporting, and asset tracking capabilities.
When: November 19th, 5:45 – 7:30 PM
Where:
Microsoft Solution Center at Bennett Adelson
6050 Oak Tree Blvd. Suite 150
Independence, Ohio 44113
Who: Lead by Jason Condo, Bennett Adelson
What: System Center Configuration Manager 2007
To register and for any questions, please reply to ncicerchi@bennettadelson.com. We look forward to you joining us!
If you have ever seen this error referring to proxying needing turned on for your OpsMgr Management Servers, the error can be misleading.
Alert: Agent proxying needs to be enabled for a health service to submit discovery data about other computers.
Source: SERVERMP01.contoso.com
Path: SERVERMP01.contoso.com
Last modified by: CONTOSO\OpsMgrAdmin
Last modified time: 9/11/2008 6:14:43 PM Alert description: Details:Health service ( 37BCD2D5-B326-759F-ECAC-101C5686D158 ) should not generate data about this managed object ( F7EC25A7-B73F-9EF0-6F54-E6412C4D22DD ).
Alert view link: "http://SERVERMP01:51908/default.aspx?DisplayMode=Pivot&AlertID=%7be3caf6e9-d5c6-40b7-bda7-a6d2878ff6a0%7d"
Notification subscription ID generating this message: {9485BB60-F40A-73B2-0116-258366F705A1}
Your first thought might be that your Management Server doesn't run an agent, so why would it need proxying turned on? Also, you will find that proxying is enabled by default on Root Management Servers to begin with, so what does this really mean?
Well, let me help you identify where you actually need to have the proxying enabled. Using the following PowerShell script (thanks Boris - http://blogs.msdn.com/boris_yanushpolsky/archive/2008/01/24/troubleshooting-event-id-33333-logged-by-the-data-access-layer.aspx), you will be able to identify the real agent that is causing the alert to be raised.
Get-MonitoringObject -id:'<GUID from alert>' | ft DisplayName
In the above alert, I would run with the initial GUID provided in the alert details ...
Get-MonitoringObject -id:'37BCD2D5-B326-759F-ECAC-101C5686D158' | ft DisplayName
... to find out that I need proxying enabled on my domain controller. This is because I had the Active Directory Server 2003 Discovery Management Pack installed and the DC is used to discover the AD topology. There are additional times that you may need this, as for discovery in clustered services, but the most common time I have seen it is in initial installations when adding the AD Management Packs (Since most installations want this).
So before you go enabling discovery on all of your secondary MSs, run the above script and save some time and headache.
During the process of adding a Gateway server for an Operations Manager environment, I received the following error while adding a certificate using MomCertImport.exe.
The certificate is valid, but importing it to certificate store failed.
Error description: Catastrophic failure
Error code:0000FFFF
Now to me, a catastrophic failure makes me think the server is going to burst into flames. While I doubt that will happen, I think someone had a good sense of humor when they wrote that message.
Some quick research didn't help me resolve why I got his error, other than asking whether the other users having this issue had stepped through some magical documentation, as if it would inspire some fairy dusted insight and everything would just click. While documents with instructions are great, they don't help allot if you don't understand what you are clicking on and what to do if your prompts or environment isn't as described in the document.
This is not to say that the following two resources are not useful, as they are quite so. I would recommend both of these resources, although it is also good to understand PKI and certificate management before blindly following instructions on setting up your environment. I mean, how do you know that what some document on the web is telling you isn't going to open you up to vulnerabilities or just malicious.
For securing your OpsMgr environment refer to System Center Operations Manager 2007 Unleashed, Chapter 11 Obtaining a Certificate. It has great step by step instructions, although I did find some missing steps. Additionally, this web doc was a good resource and built upon the knowledge from the above book, although it had more step by step instruction that if you were not already familiar with the processes could require just blind faith in implementing. Great for a lab but not for blindly building your production environment. http://www.systemcenterforum.org/ops-mgr-2007-gateway-server-and-pki-scenarios-document/
Anyway's, I easily resolved the issue and had a couple words of wisdom from my trials. Note, all of the following information assumes that you have read the documents from above. Using MomCertImport, there are two options available in the tool.
The first (given in both the examples above) uses the exported PFX certificate file. This is used by opening a cmd shell and executing: "MomCertImport <path to PFX Cert file>" with the optional "/Password <password>" added to the end. If you don't specify the "/Password" parameter, the tool will just prompt you for it. Mind you, if you export the Cert without specifying a password, you will not be able to import it because the utility will not take NULL passwords.
The second option is to use the "/SubjectName" parameter for the tool. This allows you to use the installed cert without exporting it to a file and possibly opening your cert to being compromised if you have a simple password (I bet half of you use some variation of "password" when exporting) and the file falls into the wrong hands. The command would be like "MomCertImport /SubjectName <subjectname>". The subject name comes from cert if you view the details of it from the MMC. (Note that you gave the subject name when creating your request for your cert, it was the FQDN name of the server).
Now come the problem of why the catastrophic failure occurred and why everyone says to refer to the documentation. When executing MomCertImport using the file, the cert will be opened and then will be validated against the root authority, while using the subject name option will assume the certificate is validly installed and will just use its information. Either option will then pull the serial number from the cert and put it in the registry for the OpsMgr Health Service to use. While this works fine on domain resources that request certs from enterprise CAs, if you cert was requested from a server or client that is not part of the PKI infrastructure, then the cert you get and install will not be able to be validated against the root authority. This is because the Root CA that you requested the cert from does not also have a certificate in your trusted roots store.
You can validate this by observing the first page of the details of you certificate. If it says that it installed but is not valid, then you may want to refer to the web document above about "Retrieving and installing the Root CA certificate". Now the workaround to the catastrophic failure was to use the SubjectName parameter, but you can then imagine what my next problem was. I spent a bit of time troubleshooting supposed communication/firewall errors because even after using the tool and seeing the cert serial number in the registry, I was not able to get the gateway server to talk to the management server. After authorizing the gateway server on the management server (the one that had a external FQDN with a hole for port 5723 into the internal network) I was seeing error in the eventlog talking about opening the communication to the management server but that the management server closed it.
Obviously this was a cert issue. Just as I was going to blow all the certs away and start the process back from the beginning, I saw the cert error in the MMC and it all came to light so quickly. Right after adding the Root Authority cert, everything worked. Now this could have been resolved quickly if I had just paid attention to the instructions (although the book didn't refer to this) or if the error message on the utility would have been better.
So to wrap it up... First, my servers did not catch on fire, so the "Catastrophic Failure" was way overstated (although it did cause some pain). Second, making sure that you have valid root authorities for your installed certificates is important (whether they are yours or from the external CA that issued your cert). Third, don't just blindly follow documents or instructions without understanding why you are filling specific fields or using specific names. I see this many time when assisting others in troubleshooting certificates on webservers and ConfigMgr.
Actually, I can't believe I didn't catch my cert error in the first place. I hope this helps you save some time, whether it is for OpsMgr or for something else.
Not. While useful for developers, trace logs and debugging should not be accessible to external visitors. Not only does it allow the user to peak inside your directorystucture, code snippets, and possibly even values, running code with debugging assemblies or flags enabled adds overhead to your servers.
as a general rule, you should ensure that debugging is turned off for public facing sites.
I have been an advocate of branding systems so that automation scripts and reporting can be executed to get the information branded. While SMS and ConfigMgr clients can read information from a system and dump it to a database, it is only as good as the information gathered and generally cannot be referenced when executing installs or non-SMS functions. In addition, sys admins have come up with some pretty ingenious ways to make changes to reports or editing the def.mof to manipulate the data to get results they want from a database they didn't design.
This brings me back to working on Enterprise Branding scripts. The way I see it, if I can collect some information that is frequently changing, evaluate whether the change is warranted, and place the information on the system local to the change, then I can use that information in many different ways later. If you are scratching your head and wondering what I mean, let me give you an example.
What if you need to identify who is the owner of a computer in an environment where users share PCs, so that you can push software out to the user. In today's world, you would rely on ConfigMgr queries for last logged on user or AI reports or worse yet, just push to the user and forget about licensing issues. These solutions can be spotty and do not take into account real-world use of systems, let alone pushing software to a user who logs into a lot of systems or even servers. Well, I say who better to know the common user of a PC than the user themselves.
By running an application/script at logon, based on information gathered from previous logons, I can evaluate whether the user is a first time logon or frequent logon. Based on that information, I can then decide whether to prompt the user to become the "computer owner" and save the results into a local place on the system (In this case, a registry key). I can then use that information during install processes, management scripts, and even having ConfigMgr gather the information for queries and reporting later.
Enterprise Branding is a way of gathering only specific information that you would want to evaluate and use, whether through SMS or other means, and placing it into a common location for your use later. This could be a registry location, WMI, Environment Variables, or even static files (IDMIF, NOIDMIF, or your own custom log). The key is identifying the information that is most valuable to you, deciding how you would most likely use it, and then based on that, a place to save it.
For example, if you were going to use the information in logon scripts, then an environment variable might be the easiest way to use the information. If you want to use it in ConfigMgr, than maybe putting it in WMI or the registry would work best. The cool thing is that you can then build automation around the expected information and use it to your advantage. Some examples:
- identifying the main user for user state migration before rebuilding a computer
- identifying the common user to make specific registry changes to their profile
- recording asset information for system update scripts or quick reporting
- identifying the main user of a computer to target deployments to (logic in the install would evaluate whether the current user getting the deployment was that main user of the computer)
- identifying the department or physical location of a computer to target deployments to it.
Here is an example script I was working on that would be shown when the system was first deployed to a user. Logic in the script would identify if information had changed and then display the form to the user to make changes. This information was written to the registry and then was imported to SMS through customizing the def.mof or IDMIF files.
The whole reason I bring this up is because I was in the forums and came across an issue someone was having and they were working quite hard on making mof changes to read a registry key for information. I had mentioned that I had previously worked on Enterprise Branding scripts and there seemed to be an interest. One of the benefits of starting this project back up is that a common tool would create some common registry paths that could make a simple mof change for use in SMS or ConfigMgr. If there seems to be an interest, let me know and I will start this back up.
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
More Posts
Next page »