If you need to run load tests (or any other tests) against your web application, the most efficient way to do it is to use "the cloud": Amazon Elastic Cloud or Windows Azure servers. Why? Two simple reasons:
- It's easy spin up as many servers as you need, which make it easier to scale up or down your test rig environment
- It's external to your environment, which is necessary to make your tests closer to a real life scenario
I won't bore you with details on how to set up your TFS environment and all. We're all adults; we know how to read install guides. I will only cover the things are not in any of those guides.
Server instance setup in Amazon EC2 (applicable to Windows Azure as well):
- Pick large instance type or better. Small instance just is not powerful enough.
- Use Windows Server 2008 operating system as host. Amazon EC2 does not support Windows Server 2008 R2 yet, and there is no good reason to still use Windows Server 2003 operating system.
- Use an instance with SQL Server 2008 Express pre-installed to save time, unless you think your databases will be larger than 4Gb (very unlikely scenario in this cases)
- When going through "Launch an instance" wizard, at the Security Groups screen, pick Default group and create new security group (you don't have to configure new security group now, this can be done later). Make sure both of those groups were selected as this will save you a lot of headache later.
- Assign public IPs to your "cloud" servers and make sure that ISP that hosts your web application does not block or quarantine those IPs.
Host OS setup:
- Disable Simple File Sharing. I am not sure why this feature is enabled on the servers.
- Add your service account(s). To keep these notes simple, we will stick with one service account: tfsservice. Make sure all of your server instances have the same user accounts added (with the same passwords, of course)
- If you're feeling lazy, grant your service account a local administrator's permissions
- Make sure all of your "cloud" servers can see one another. If not, tweak your security groups in AWS Management Console.
TFS 2010 server tweaks:
- Make sure that the user account with the same name and password as the service account on the cloud servers exists in the environment that hosts TFS 2010. Could be a local account on the TFS server or domain account.
- Make sure that this service account is a member of Project Collection Administrators group, Project Collection Service Accounts group, and Project Collection Test Service Accounts group. Use tfssecurity.exe to add your user to those groups, if GUI does not let you.
- In some cases, using SSL when connect to your TFS server does not work, so configure your TFS server to accept connections on HTTP port as well (for example, port 8080)
Test Controller configuration:
- Make sure that the account you're using to run Test Controller service is a member of TeamTestAgentService local group
- Always use ".\" instead of a domain name or machine name when provide credentials. For example, ".\tfsservice", instead of "SERVERNAME\tfsservice"
- Do not register your test controller with any TFS project collection just yet
- Enter SQL Server instance that will be hosting your Load Test database
- Add virtual user licenses
Test Agent configuration:
- Always use ".\" instead of a domain name or machine name when provide credentials. For example, ".\tfsservice", instead of "SERVERNAME\tfsservice"
- Enter the machine name of your test controller. Use port default port 6901, unless you have configured your test controller to listen on a different port
I hope you found this info useful. If you have any questions or comments, shoot me an email at max [at] objectsharp [dot] com.
Just wanted to share this funny looking error I got on a SharePoint 2010 server recently: http://twitpic.com/3guyk8
I have no idea how or why this happened, but after I have refreshed the page it was gone and I never got it back. No errors were posted in the logs either J
Recently I have run into the situation where I was performing some maintenance work on SharePoint (backups, applying patches, you know – that kind of stuff), but the existing database connections to SharePoint were preventing me from doing my work. The way around this was to kill the remaining database connections, and here is how this can be done:
- Open SQL Management Studio
- Go to Management, and right click on Activity Monitor. Click on View Processes to get the list of all database connections
- Sort by a connection to a specific SharePoint database.
- Right click on a connection and click Kill Process.
- Do the same for all database connections to SharePoint, and you can carry on with your SharePoint maintenance tasks
Well, I was looking through SharePoint web.config file one time and asked myself how SharePoint knows where to find its contents. I know, it's a weird question to ask, but what can I say… I am that kind of person. Anyways, obviously looking through web.config did not yield any results, so I looked googled it. By the way, I do not know why, but I keep calling searching online as "googling" even though I switched to Bing a while ago. Old habits die hard, I guess, but I digress… After a little of research, I have found this blog post that has explained how SharePoint 2010 or 2007 finds its content. Basically, this is how it works:
- User types in the URL of the SharePoint website
- IIS gets a HTTP request, then handles it based on port number or a host header specified in the request
- Matching SharePoint website hands all requests to ASP.NET (thanks to wild card ISAPI mappings), which does all kinds of magic with the request
- Then, SPRequest HTTP module (defined in the web.config) gets into the play. SPRequest module does its magic too, and eventually request the location of the SharePoint configuration database from the registry. Connection string for the SharePoint configuration database is set using DSN key at HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB (for SharePoint 2007) or HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure\ConfigDB (for SharePoint 2010). So, this is the registry value, you need to change, if you ever need to move configuration database.
- SharePoint configuration database knows where everything about the SharePoint farm, so it is (relatively speaking) "no brainer" from that point on… and the user sees an awesome SharePoint page on the screen.
It's that easy J
Recently, I have been installing and configuring a lot of TFS 2010 environments. Really, a lot of TFS 2010 (production, test, proof-of-concept) servers. Occasionally, I anger TFS "gods", so TFS installer throws an error and complain that certain TFS components does not have enough memory complete the install. It turns out that SharePoint component of TFS environment requires minimum of 1Gb of memory to operate. So does, TFS Build server… Otherwise, you'll end with this error in the installer log: " TF255157: The amount of RAM available on this computer is not sufficient to complete this process. You must have the following amount of RAM available: 1024 MB…"
Usually adding more memory to the servers hosting TFS components solves the problem, but if you can't wait to start playing with awesome TFS 2010, here is how you can override TFS 2010 installer behaviour:
- Create new environmental variable called TFS_IGNORE_VMEMORY and set its value to 1
- Restart your Team Foundation Configuration Wizard (not the entire server), and this time TFS "gods" will like you again.
Please note, just because you bypassed memory constraints preconfigured in TFS 2010 installer, it does not mean that you should not add more memory to your servers. Your TFS 2010 servers will work so much better, when its server meet (or exceed) the memory requirements…
Top ten facts about Chuck Norris and SharePoint 2010:
- Chuck Norris never starts an Approval workflow in SharePoint. Chuck doesn't need approval.
- Chuck Norris isn't afraid to customize, one look and SharePoint runs at peak performance
- Putting Chuck Norris in the SharePoint Visitors group is futile. Chuck always has Full Control.
- Chuck Norris doesn't have a SharePoint Disaster Recovery Plan. He doesn't recover data, only hostages.
- Chuck does not subscribe to Alerts. He knows what is happening before it happens.
- Chuck Norris IS the Governance Plan
- In SharePoint 2010, the Farm Administrators group is being renamed to 'Chuck's Group'.
- Chuck Norris never get's unexpected errors with SharePoint because he is always ready for everything.
- Chuck Norris doesn't prepare for SharePoint 2010. SharePoint 2010 prepares for him.
- SharePoint 2010 was a Chuck Norris idea.
Read more hilarious Chuck Norris & SharePoint 2010 facts at http://www.sharepointcomic.com/archive/2009/10/19/sharecomic-chuck-norris-and-sharepoint.aspx.
SharePoint 2010 allows administrators to pre-configure service accounts to be used when configuring SharePoint components. This way administrators don't have to remember or lookup usernames and passwords for service accounts every time they configure a new web application or SharePoint service. To configure managed service accounts in SharePoint 2010:
- Open SharePoint Central Administration
- Click on Application Management | Manage Web Applications
- Click on New button on the ribbon
- Fill in the text fields in IIS Website, Security Configuration, and Public URL sections, until you reach Application Pool section. This is where the fun begins...
- You can use one of already preconfigured managed accounts or create new one. To use an existing managed account simply pick one from the drop-down list. To create new managed account, click on Register New Managed Account
- Fill in the username and password fields (Note: for some reason there is no "confirm password" field, so make sure you type the password correctly the first time.) This screen also allows you to configure Automatic Password Change schedule. Pretty neat.
- Click OK to save newly configured managed account. Now you're back at Create New Web Application window, where you can see your managed account in the drop-down list.
- If administrators want to pre-configure managed accounts, they can do so in the SharePoint Central Administration. Click on Security | Configure managed accounts (under General Security section). Click on Register Managed Account to configure new managed account, or click on Edit to make changes to an existing managed account.
Just thought it was a good tip to share...
If you're getting "Access to the path 'C:\ProgramData\Microsoft\Team Foundation\Web Access\Cache' is denied" error when you try to access TFS 2010 Beta 2 via the Team Web Access, the problem most likely lies with missing NTFS permissions on the above-mentioned Cache folder. This problem often happens when you're running your TFS 2010 server on a domain controller, which is not ideal, but sometimes unavoidable, especially if you run all-in-one server setup.
There are two possible workarounds:
- First workaround is to assign Modify NTFS permissions on Cache folder on the TFS server to the service account used by SharePoint application pool in your TFS environment. Most likely, your SharePoint application pool (by default) runs under Network Service built-in account.
- Second workaround is changing SharePoint application pool to run under a domain account instead of Network Service account. I have read somewhere that this problem is caused by the fact that Network Service account cannot be added to a global group TFS_APPTIER_SERVICE_WPG, which is a domain group, not local to your TFS/DC server.
Note: If Cache folder does not exist, create one J
I recently came across draft guidelines from Microsoft that describe the requirements and considerations for planning to upgrade to SharePoint 2010. It's a one page document. It's easy to read to and to the point. I found it quite useful. Microsoft describes this document as:
"This model covers planning for an upgrade from Microsoft Office SharePoint Server 2007 or Windows SharePoint Services 3.0 to SharePoint 2010 Products.
It includes information about the following: Upgrade requirements: Hardware, operating system, and database
Upgrade process: specific steps to follow before, during, and after the upgrade"
You can download it from Microsoft Download Center: http://www.microsoft.com/downloads/details.aspx?FamilyID=eef6f604-9faa-4ea8-b000-569c656b7420&displaylang=en
If you need to run SharePoint 2010 on a domain controller, then you have to run the following PowerShell command on your SharePoint server to enable Sandboxed Solutions:
$acl = Get-Acl HKLM:\System\CurrentControlSet\Control\ComputerName
$person = [System.Security.Principal.NTAccount]"Users"
$access = [System.Security.AccessControl.RegistryRights]::FullControl
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]::None
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person, $access, $inheritance, $propagation, $type)
$acl.AddAccessRule($rule)
Set-Acl HKLM:\System\CurrentControlSet\Control\ComputerName $acl
This PowerShell command will add an ACL access rule on your server, without which SPUCWorkerProcess.exe process won't start even though Microsoft SharePoint Foundation User Code Service will start.
P.S.: It's never a good idea to run any server applications (including SharePoint 2010) on your domain controllers, so please avoid it whenever possible.