HTTP error 403 in SharePoint

The solution is blindingly obvious once you understand it, but then isn’t it ever thus. Certificate errors, folder permissions, port numbers, SharePoint access levels, intricate IIS problems, public domain dns errors and all those issues you find when you Google “SharePoint Error 403 Windows Server” are largely red herrings. That is NOT to say that you can ignore these but when you know these are OK and you are still getting the error you need to find a different solution.

Starting from Basics

Platform: Windows server 2003 standard (that is NOT SBS); SharePoint V3

Problem: after configuration I could access default site on the server but not from outside – constant 403 errors.

The answer came to me via a visit to a link to Microsoft Technet on about page 4 or 5 of the Google output (it is sometimes worth going in that far!).

Fed up with getting these errors using the FQDN in the address bar [for those unfamiliar with FQDN I was typing hostname.domainname.com (please substitute your own hostname and domainname)] I typed in the IP address and got a connection. That proved that there was a route through to the site and that certificates and folder permission were NOT the issue.

The technet link [ http://technet.microsoft.com/en-us/library/cc288173(office.12).aspx ] gives you the basics but it is still a bit cranky. I am not going to repeat the contents of that link so keep it handy.

The Alternate Access Mapping link defaults to 'show all'. When you use the drop down you have to choose the ‘Change Alternate Access Mapping Collection’ link. You will be offered the sites in your collection – in my case ‘Central Administration’ and ‘SharePoint – 80’.

Select the site you want to change (in my case 'SharePoint -80'). You are presented with the URLs that point to this site – initially it will be something like ‘http://yourservername’.

Now this is the bit to get your head around. There needs to be a complete separation in your mind about where you are accessing the site from.

If you are accessing the site from within your network (ie intranet mode) you will need an internal URL such as ‘http://yourservername’ and then for clients working within your own domain they will need to enter this internal URL in the address bar of their browser (I can use both IE and Firefox – after all it is only a website).

If you want to access the site from outside your domain (eg from home, extranet mode) then you need to have a public URL such as ‘http://hostname.domainname.com’ and then clients need to put this URL into their browser when accessing the site from outside the domain.

So now you have 2 URLs to the same site.

Your users will have to get used to the idea of using the internal URL when they are at work and the public URL when they are at home.

I was so pleased that I had cracked this last night once I had changed the Public URL that it came as shock this morning when I could not access the site from the server on which it resides which was resolved once I re-entered the internal URL.

As an administrator you also need to be very sure that you are setting the URL details when the ‘Alternate Access Mapping Collection’ is lodged on to the correct site. Otherwise you could be changing the URLs for a different site.

We are happy to take requests for further information on this. Please visit www.hillierconsultants.com or email stephen@hillierconsultants.com for further help.

The security database on the server does not have a computer account for this workstation trust relationship.

We recently has this error message appear when trying to log on Windows 7 workstations to our Windows 2003 domain server.
"The security database on the server does not have a computer account for this workstation trust relationship."
We trawled through the Google searches for this message and there are pages of reports of this error.
Let me give you the circumstances.
Our domain server failed. We could not get it to get through POST and BIOS to try to find and operating system. That was the first big 'Ouch'.
So we rebuilt the server on to new hardware and configured it, as we thought, the same. We initially had some issues with DNS and NICs not doing as they should but the upshot was that our 2 Windows 7 workstations could not connect to the domain. Please note this did not affect our remaining XP workstation which logged just fine.
After looking at the Goggle responses we noticed that we had rebuilt the domain but missed off the '.local' on the domain name.
So we rebuilt being more careful next time. Even so we got a capital letter in the wrong place in the domain name. So we rebuilt a third time. This time we are sure we got everything right. It made not a jot of difference.
Other websites had suggested we disconnect from the domain and reconnect to the new domain. Not an iota of difference.
Finally we had to reinstall the operating system on both our Windows 7 machines.
One side effect of this, despite having installed onto completely new hard disks to preserve the data on the old disk, is that on one of the machines we have lost ALL out Outlook pst files. Some emails going back 6 years with important information.
Couple this with the total data loss of all information on the server did not make us very happy.
I will finish with this comment. Why, oh why, Microsoft is it so hard to get your systems to talk to each other. This is hardly a ringing endorsement for the improvements in Windows 7 when XP performs better in what was already a very fraught situation. Please try to do better next time.