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
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.
If you're getting a blank page when you are trying to access SharePoint Central Administration site, then check your IIS settings. To be more specific, check the authentication settings for SharePoint Central Administration website in IIS. Make sure that you have Windows Authentication enabled and Anonymous Authentication disabled.
This must be the shortest blog post I have ever written. But taking into consideration that it was written on the first day of work after the holiday season, it's not so bad. Happy New Year everyone!!! J
It is definitely possible to use SharePoint 2010 beta 2 with TFS 2010 beta 2. You don't even need to do a lot of work to get them working together. A few things to consider:
- SharePoint 2010 beta 2 must be preinstalled (either on the same or separate machines) since TFS configuration wizard will not install SharePoint 2010 for you (only can only install WSS3)
- You need to manually enable TFS to log diagnostics information to SharePoint 2010 logs, because Microsoft changed the trace mechanism used in SharePoint 2010. To do that open SharePoint 2010 Management Console and type in
Set-SPDiagnosticConfig –AllowLegacyTraceProviders
- Since we are dealing with beta products, some things in the project dashboards might look a bit funny in IE8
- And last, but not least, if you decide to go with SharePoint 2010, do not forget to allocate a LOT of memory to SharePoint server (physical or virtual) because SharePoint will need it to function properly.
If you want to install and configure SharePoint 2010 in a standalone environment, but you do not want to use SQL Express and/or if you it to run in a workgroup environment, by default SharePoint 2010 configuration wizard will not allow you to do that. There is a way to get around this limitation though:
- Open SharePoint 2010 management shell, (you can find it at the same location as the SharePoint Central Administration link)
- Type in New-SPConfigurationDatabase to create new SharePoint configuration database manually
- Enter the name of the new SharePoint configuration database and hit Enter
- Enter the credentials that you want to use to create new SharePoint configuration database. Enter the password for those credentials when you get prompted to type in a passphrase and hit Enter. Your new SharePoint configuration database will now be created, just wait a few seconds/minutes.
- Run SharePoint configuration wizard, select Do not disconnect from this SharePoint farm option and continue with the configuration...
Yesterday I have witnessed a very weird behaviour of SharePoint navigation menu. Basically, SharePoint refused to save any changes (add/remove, hide, move, etc.) to SharePoint navigation menu. To make things even more confusing, it did not throw any errors or warnings in the event logs or SharePoint logs when this happened! In the process of troubleshooting this problem, we have systematically eliminated navigation provider(s), master pages, pages layouts, web.config(s), etc. as a potential source of this problem. We have checked everything and we're not able to come even close to finding a solution. Just before we started to plan on rebuilding the entire SharePoint environment to solve the problem, we have (almost accidently) found what was causing the problem. It turns out that what was causing this weird behaviour is that a default value of a single Boolean variable (_spSuppressFormOnSubmitWrapper) in INIT.JS file was changed from FALSE to TRUE. This almost makes sense, but... If you change the default behaviour of the submit button, shouldn't this change for effect the entire SharePoint environment, instead of singling only the navigation menu? Weird?! I am glad the problem was resolved though J