Can't open Excel file on Microsoft Office SharePoint Server 2007 Problem

When you try to open a specific excel document from a Shared Documents section on a SharePoint Site, Maybe excel pops an alert window:

Microsoft Office Excel cannot access the file http://.../Shared Documents/file.xls. There are several possible reasons:

•The file name or path does not exist.
•The file is being used by another program.
•The workbook you are trying to save had.....etc

The major reason for that issue that you need to increase the connection time out (6 minutes is recommended) on the web site that host the SharePoint site on IIS.

Where the connection time-out setting is not allowing enough time for you to open a specific excel sheet.

To set a connection time-out value for a specific Web site:

1. In IIS Manager, expand the local computer, expand the Web Sites folder, right-click a Web site, and click Properties.

2. On the Web Site tab, in the Connection timeout box, type the maximum number of seconds that IIS should maintain an idle connection before resetting the connection.

Configuring Websense 7 software to ignore specific traffic from ISA 2006

To prevent filtering and logging of this traffic, add the user names, host names, and URLs that you do not want Websense software to filter to the isa_ignore.txt file.

1. On the ISA Server machine, open the isa_ignore.txt file in a text editor. This File is located in the WINDOWS\system32 directory.

2. Enter each user name, host name, or URL that you want Websense software to Ignore. Enter each item on its own line in the file, using the formats below.

􀂄 User name: Enter the name of a user whose Internet requests should not be filtered or logged by Websense software:

username=
Examples:
username=jsmith
username=domain1/jsmith

􀂄 Host name: Enter a destination host name that Websense software should not filter or log user visits to:

hostname=
Example:
hostname=yahoo.com

􀂄 URL: Enter a URL that Websense software should not filter or log user visits to:

url=
Example:
url=http://mail.yahoo.com/
url=mail.yahoo.com/

Then run a ISA debugging tool to check if the URL has been correctly recognized.

1. Open the file wsMSP.ini located in C:\Windows\system32 where the Websense ISAPI filter is installed.

2. Create a new section in the wsMSP.ini file called [diagnosticSection] with the following values:

[diagnosticSection]
ProgressTraceType=FileOnly
ProgressTraceMask=1
ProgressTraceFile=C:\Program Files\Websense\bin\wsISA.txt DumpUserNames=any

Note: Please change the security of the bin folder to be full controlled by everyone temporarily.

3. Stop then start the MSP/ISA Server Web Proxy which can be done through the MSP/ISA Manager. Restart Microsoft Firewall service in the service management console.

4. Browse the sites that you have added in the isa_ignore.txt file. A file called wsISA.txt will be generated in C:\Program Files\Websense\bin\ directory.

5. Please open this file to see if the URLs recorded are the same as you wrote in the isa_ignore.txt file, and if the file has taken effect.

Note: Please delete those lines in the wsMSP.ini file when you finish the test.

6. If the URLs in isa_ignore.txt file is correct, the following lines will be displayed in the isa debugging file:

OnPreprocHeaders: user: mvia: via: raddr:172.17.2.163 url:http://www.ibm.com/ meth:GET ver: HTTP/1.1 host:www.ibm.com userAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) This url or hostname is ignored.

File Share error Event ID:2011

When you access shared items on a Windows server 2003 from a Windows XP client, you may receive the following error message:

Not enough server storage is available to process this command.

The following events may also be logged:

To resolve this issue, increase the value of the IRPStackSize registry entry. To do this, follow these steps:

1-Click Start, click Run, type regedit, and then click OK.

2-Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

If the IRPStackSize entry is not present in this subkey, follow these steps:

        a. Click Edit, point to New, and then click DWORD Value.

        b. Type IRPStackSize, and then press ENTER.

Note: Type IRPStackSize exactly as it appears. The value name is case sensitive.

3-Click IRPStackSize, click Edit, and then click Modify.
4-In the Data Value box, type a larger value, and then click OK.

Note: Values may range from 0x1 to 0xC. These values are equivalent to 1 to 12 in decimal.

If the problem persists, increase the value of IRPStackSize more.

Configuring round robin

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Configuring round robin:

Round robin is a local balancing mechanism used by DNS servers to share and distribute network resource loads. You can use it to rotate all resource record (RR) types contained in a query answer if multiple RRs are found.

By default, DNS uses round robin to rotate the order of RR data returned in query answers where multiple RRs of the same type exist for a queried DNS domain name. This feature provides a simple method for load balancing client use of Web servers and other frequently queried multihomed computers.

If round robin is disabled for a DNS server, the order of the response for these queries is based on a static ordering of RRs in the answer list as they are stored in the zone (either its zone file or Active Directory).

Example: Round-robin rotation:

A forward lookup-type query (for all A RRs that match a DNS domain name) is made for a multihomed computer (multihomed.example.microsoft.com) that has three IP addresses. Separate A RRs are used to map the host's name to each of these IP addresses in the zone. In the stored example.microsoft.com zone, the RRs appear in this fixed order:

multihomed IN A 10.0.0.1

multihomed IN A 10.0.0.2

multihomed IN A 10.0.0.3

The first DNS client that queries the server to resolve this host's name receives the list in default order. When a second client sends a subsequent query to resolve this name, the list is rotated as follows:

multihomed IN A 10.0.0.2

multihomed IN A 10.0.0.3

multihomed IN A 10.0.0.1

Restricting round-robin rotation for selected RR types:

By default, DNS will perform round-robin rotation for all RR types. You can specify that certain RR types are not to be round-robin rotated in the registry. There is a registry entry called DoNotRoundRobinTypes (REG_SZ) with a string value containing a list of RR types. By modifying this entry, you turn off round-robin rotation for specific RR types. For example, to prevent round-robin rotation for A, PTR, SRV, and NS record types, you would enter the following value for the registry entry: A PTR SRV NS

Restricting round-robin rotation for all RR types:

The default setting for round-robin rotation is contained in the registry entry RoundRobin (REG_DWORD). By default, this entry's value is 1, rotating all RR types except those listed in the DoNotRoundRobinTypes registry entry. If the value of RoundRobin is set to 0, then no RR types will be round-robin rotated.

Caution:

• Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.

Notes:

• The string value for the DoNotRoundRobinTypes registry entry may contain types in numeric (as shown above) of mnemonic formats.

• Both of the round robin registry entries must be created and stored in the following registry subkey:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

• Local subnet priority supersedes the use of round-robin rotation for multihomed names. When enabled, round-robin continues to be a secondary method used to sort multiple RRs returned in a listed answer.

Enable address conflict detection

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

To enable address conflict detection:

1. Open DHCP.

2. In the console tree, click the applicable DHCP server.

3. On the Action menu, click Properties.

4. Click the Advanced tab.

5. For Conflict detection attempts, type a number greater than 0 (zero) and less than six, and then click OK.

The number you type determines how many times the DHCP server tests an IP address before leasing it to a client.

Notes:

• To open DHCP, click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click DHCP.

• When conflict detection attempts are set, the DHCP server uses the Packet Internet Groper (ping) process to test available scope IP addresses before including these addresses in DHCP lease offers to clients.

• A successful ping means the IP address is in use on the network. Therefore, the DHCP server does not offer to lease the address to a client. If the ping request fails and times out, the IP address is not in use on the network. In this case, the DHCP server offers to lease the address to a client.

• Each additional conflict detection attempt delays the DHCP server response by a second while waiting for the ping request to time out. This increases the load on the server. A value of no greater than two (2) for ping attempts is recommended.

Information about functional differences:

• Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.

Integrating DNS with WINS

This section will review:

• How Integration Works. This section explains why it's a good idea to make WINS and DNS cooperate. Multiple-platform networks can benefit by providing several kinds of name resolution to various clients with different client configurations.

• Enabling WINS Lookups. This section shows how to establish WINS lookups through a DNS server.

• Testing WINS Lookups. This section shows how to be sure that WINS lookups through DNS are working properly.

• Reverse Lookups with WINS. This section shows how to establish reverse lookups through DNS for clients that register to a WINS server.

• Multihomed Servers. WINS typically does a good job of handling multihomed computers. This section shows how to provide multihomed resolutions through DNS for WINS-registered computers.

Mixed networking environments are today's norm. A multiple-platform network can have a UNIX-based server to handle DNS requests and a Windows NT-based server to handle WINS requests, but this means you'd spend a lot of time administering two separate name resolution methods. Windows NT 4.0 cuts this administrative overhead by integrating both name resolution methods.

DNS and WINS both participate in resolving host names and computer (NetBIOS) names to IP addresses in a typical Windows environment. They help you resolve names so you can connect to remote computers across the LAN and across the Internet. WINS resolves computer names that are flat names, such as \\EARTH, and DNS resolves FQDNs, such as earth.paradise.com.

How to redirect an HTTP connection to HTTPS for Outlook Web Access clients and how to redirect the Default Web Site to point to the Exchange virtual directory

This article describes how to automatically redirect an HTTP connection to an HTTPS connection in the Internet Information Services console (IIS) for Microsoft Office Outlook Web Access (OWA) users. This article also describes how to modify the IIS Default Web Site so that clients can access the Outlook Web Access logon page by typing only http:// instead of typing http:///exchange.

We recommend that you require a Secure Sockets Layer (SSL) connection for your OWA users. An SSL connection encrypts the information that is sent to or received from the Microsoft Exchange Server computer. However, when you configure IIS to require SSL for all incoming OWA requests, OWA users who try to connect by using HTTP receive the following error message:

HTTP 403.4 - Forbidden:
SSL required
Internet Information Services

After the OWA user receives the error message, the user must manually type https:// at the start of the URL to connect to the Exchange Server computer. You may want to configure IIS to automatically redirect the OWA user's HTTP request to HTTPS to minimize user interaction and to make sure that all incoming requests are enabled for SSL.

Establishing Cross-Realm Trust between Active Directory and Novell KDC

Overview:

This AppNote describes the process of logging in to a Windows XP member machine with Novell KDC credentials, using Interoperability between Novell KDC and Microsoft KDC (Active Directory).

Objective:

The objective is to log in to a Windows machine that is part of an Active Directory Domain, using credentials of a user principal in a Novell KDC realm. Cross-realm trust is used between Active Directory and Novell KDC.

This AppNote will explain how to configure cross-realm trust between Active Directory and Novell KDC, so that any Novell KDC user should be able to log in into domain member machine of Active Directory.

Prerequisite:

Novell KDC1.5 and Active Directory (with Windows 2003 Server) should be installed and be able to contact each other.

Establishing Cross-Realm Trust:

A cross-realm trust is established between the Novell KDC realm and Active Directory so that Novell KDC users are authorized for access to resources inside of the Active Directory domain. Also, because users can log in to member machines of the Active Directory domain, they can access Windows services seamlessly.