When working with the Search feature in Microsoft Office SharePoint Server (MOSS) 2007 you may have encountered the following error:
Access is denied. Check that the Default Content Access Account has access to this account, or add a crawl rule to crawl this content.
I have experienced this error on Windows Server 2008 R2 (and SQL Server 2008) as well as Windows Server 2003 R2 (and SQL Server 2005). In both cases I was running MOSS 2007.
SOLUTION 1 - Specify the Content Access Account & Password
To resolve this error, the most obvious thing to try is to add the Content Access account to the crawl rule as described below. However, this may not solve your problem. In any case, try this method first before you try solution 2.
1. Go to Central Administration and click on the Shared Services Provider (SSP) where you want to configure search.
2. From the home page of the Shared Services Administration, under Search click Search settings.
3. In the left navigation bar, under Crawling section click Default content access account.
4. Enter the Content Access account in the form DomainName\AccountName. For example, SeattlePro\Content. Alternatively, you can also enter it in the User Principal Name (UPN) format, such as AccountName@DomainName.com.
NOTE: Some people have reported that they have fixed the above error simply by changing the format from DomainName\AccountName to AccountName@DomainName.com. However, that solution didn’t work for me.
SOLUTION 2 – Disable the Loopback Check
Another solution is to disable the loopback check by setting the DisableLoopbackCheck registry key. The loopback check security feature is designed to help prevent reflection attacks on your computer. Therefore, disabling it has its consequences. Microsoft describes the disabling of loopback check in more detail in KB896861. Here’s how.
Follow these steps to set the DisableLoopbackCheck registry key:
WARNING! There’s one thing that you ought to know about disabling the loopback. It’s okay to disable it in a test/development environment but not in a production environment. Microsoft SharePoint MVP Spencer Harbar has written a blog post about the consequences of disabling loopback in the production environment that is a must read.
If you are using Word as your editor in Outlook 2007 and are unable to convert Internet addresses, such as http://www.techgalaxy.net/ to http://www.techgalaxy.net/, you may need to make a change in the Word AutoCorrect option.
Here’s the procedure.
1. In Word 2007, go to the Editor Options. You can also go to Editor Options from within Outlook 2007 if you click on the Customize Quick Access Toolbar link in the title bar.
2. Click on the drop-down arrow and click More Commands.
3. In the Editor Options window click Proofing.
4. Click on the AutoCorrect Options button.
5. Click the “AutoFormat As you Type” tab.
6. In the “Replace as you type” section, check the box “Internet and network paths with hyperlinks”, as shown below. Notice that this option is also available on the AutoFormat tab. You may also want to check that box if you prefer.
There is no need to start Word or Outlook for this change to take effect.
According to Nicolas Economou, an exploit writer at Core Security Technologies, he has discovered a major flaw in the memory management of the Virtual Machine Monitor, which effects Microsoft Virtual PC 2007, Virtual PC 2007 SP1, Windows Virtual PC and Microsoft Virtual Server 2005. On Windows 7 the XP Mode feature is also affected by this vulnerability. He has discovered that the flaw causes memory pages mapped above the 2GB level to be accessed with read or read/write privileges by user-space programs running in a Guest operating system. This vulnerability exposes Microsoft’s Virtual PC virtualization software to malicious hacker attacks.
The vulnerability, which is unpatched, essentially allows an attacker to bypass several major security mitigations — Data Execution Prevention (DEP), Safe Exception Handlers (SafeSEH) and Address Space Layout Randomization (ASLR) — to exploit the Windows operating system.
Nicolas claims that a vulnerable application running in Windows XP Mode on Windows 7 may be exploitable in a virtual environment, while the same application running directly on a Windows XP SP3 operating system is not. Microsoft Hyper-V technology does not seem to be affected by this problem.
According to Ivan Arce, chief technology officer at Core, some applications with bugs that are not exploitable when running in a not-virtualized operating system are rendered exploitable if running within a guest OS in Virtual PC.
Here’s Microsoft official response to the discovery of this flaw:
“Core Security Technologies is describing a way for an attacker to more easily exploit security vulnerabilities already present on the system, rather than an actual vulnerability. It does this by rendering a number of protection mechanisms that are present in the Windows kernel less effective inside a virtual machine as opposed to a physical Windows machine. An attacker would need to abuse an already present vulnerability in order to leverage this technique.
In the scenario Core describes, the functionality is limited to within the virtualized environment– in other words, an attacker could only exploit a vulnerability in an application running “inside” the guest virtual machine on Windows XP rather than Windows 7 in the case of Windows XP Mode. Specially an attacker could not take over a whole host machine running multiple virtual machines. The safeguards within Windows 7 on the desktop OS (DEP, ASLR, and SafeSEH etc.) remain in place.
In addition, an actual vulnerability must already be present in an application running in the guest machine in order for an attacker to take advantage of this. The difference is that on a regular Windows system, that bug may not be exploitable, whereas in the Virtual PC guest machine, it potentially could be.
Microsoft continues to recommend using Windows XP Mode and Windows Virtual PC as a bridging strategy to Windows 7 if they are concerned about compatibility for some of their legacy applications, so that customers can realize the full security benefits Windows 7 offers.”
Microsoft has published a 30-page white paper that provides information and guidelines for building scripts that can automate the installation of Office SharePoint Server 2007, the configuration of servers, and the creation and joining of farms. Code samples that you can copy and customize to match your farm and configuration are included.
The script will help you setup and configure the prerequisites, install the SharePoint Server, configure the services, and create and configure the sites.
WARNING! This white paper was last updated in 2008. I should warn you that the script that creates service accounts does not include the proper domain and groups right that are necessary. Read my blog about the service accounts that are necessary to properly install MOSS 2007 and then modify your script accordingly.
Download the white paper here.
Contact E-mail | Terms of Use | Privacy Policy
Copyright ©2010 Zubair Alexander. All rights reserved.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Feb | Apr » | |||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
23 queries. 0.483 seconds