SharePoint 2007 File Upload Sizes

Just a quick post tonight. I was working on an issue where a file upload would not complete to a SharePoint server across the internet over HTTPS. I checked all the usual SharePoint settings and everything looked fine. Yet I was still getting blank pages and 404.13 errors. I was stumped until I started digging into IIS configuration. The problem was due to configuration parameters in Server 2008 with IIS7. The parameter in question was maxAllowedContentLength.

In SharePoint 2007 there are multiple configuration changes required to increase the file upload size. There are also client changes that need to be made if you're concerned about Explorer view.

First, I'd suggest following Microsoft KB article: http://support.microsoft.com/kb/925083. This will get you most of the way there.

The next step is to run the following command on your SharePoint frontend servers. Make sure you run this command as an administrator or it will not succeed.

%windir%\system32\inetsrv\appcmd.exe set config -section:requestFiltering -requestLimits.maxAllowedContentLength:104857600

The 104857600 is 100MB in bytes. Make sure to modify this for what is appropriate to your environment. Just remember SharePoint has a maximum file size hard limit of 2047MB.

Above I mentioned Explorer view, which is powered by WebDAV. From Windows XP and up you'll have to modify a registry key on the client to override the default value for allowed file sizes. The default is about 5MB which is extremely tiny in today's world. Open up regedit and modify the following value in the registry. Create it as a DWORD if it does not exist.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\FileSizeLimitInBytes

As the name suggests the value is in bytes. I suggest setting this to the maximum upload size that you use for SharePoint. If you only use this for SharePoint, just remember there is no point in setting it higher than 2047MB (or 2146435072 bytes) as SharePoint cannot work with files larger than that.

Once you have all these settings set you should be able to upload larger files to SharePoint. Enjoy!

Lync BES 5 SP3 Integration Guide

Now that RIM has released Service Pack 3 for the Blackberry Enterprise Server (BES) 5 we can now have Lync connectivity on our Blackberries. Let me tell you it works well. It took awhile to get it functioning properly but it was worth it. So if you don't already have the Service Pack, go here and get it.

Lync integration with the BES requires the the UCAPI 2.0, SQL Native Client, and OCS Core components be installed. That's right RIM uses the OCS 2007 R2 components to accomplish the connectivity. If you ask me, this is very smart since the Lync has backward compatibility for OCS 2007 R2 components. This is a two for one deal for RIM. They can support OCS 2007 R2 and Lync using same interfaces.

Once you have the prerequisite packages installed (the installer will tell you it needs them) you can then make a decision on which provisioning method you wish to use. There are two methods and they are described in detail here. I choose to use the automatic method which worked perfectly.

Now go ahead and install the BES or upgrade it. This is out of the scope of this blog; follow the RIM documentation on how to do this.

Next, you'll have to generate a certificate for the BES. More information can be found in RIM's knowledge base. Here is the article you'll want to review. Now you're probably thinking great. I know what I need in the certificate but how do I create the request? I have a standalone CA in my environment it was quite simple once you know the syntax to use in the certificate request inf file. Here is a sample certificate request inf file for the BES.


[Version] 
Signature="$Windows NT$"


[NewRequest]
Subject = "CN=lyncpool.example.com" 
Exportable = TRUE
KeyLength = 1024  
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC


[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1


[RequestAttributes]
SAN="dns=lyncserver.example.com&dns=besserver.example.com"


A few notes on the above inf file:

1. Subject must be set to the FQDN of the Lync pool that you will be connecting to in the same format as above.
2. Setting Exportable to TRUE allows you to export and transport the certificate with the private key to another server later if required or to export it and back it up. Set it to FALSE to disallow this.
3. SAN must contain the FQDNs of the servers hosting the Lync pool and of the BES server that is providing the Collaboration service. The format must be the same as above.
4. The sample file is for a standalone or external Certificate Authority. If you are using an Enterprise CA or need more information in general, take a look at this Microsoft knowledge base article. 

Once you have your inf file ready and are ready to submit the request to your CA run the following command the server hosting your BES:

certreq -new "path to your inf file" "path to the request file to generate" If you are running this on a 2008 or 2008 R2 server you will need to run this as an administrator. This should now generate the request file. You can then send that to your CA to have a certificate issued. 

Once you get the certificate back from your CA. You can install it. The easiest way to do this is to open up the MMC and add in the Certificates snap-in, select "Computer account"  and point it the "Local Computer" or another computer so long as it is the server hosting the BES. Now, open Personal, right click and select "All Tasks" and then "Import..." and follow the wizard through and be sure to select the file your CA gave you when prompted. Once the certificate has been imported, click on Certificates under Personal and then right click on the certificate you just imported and hit properties. Now, enter in OCSConnector as the "Friendly Name". Click OK and you're done with the certificate set up. The friendly name is essential, the BES seems to look for this so it knows which certificate to use.

Now here is where things went awry for me. I could log into Lync with the Enterprise IM client on my Blackberry and I could send messages but could I receive them or updated presence information? The answer was a resounding no. People that tried to send me messages got a 504 error reported to them in their Lync clients. To begin troubleshooting this, after covering all the basics, I fired up the Lync Logger and logged everything for SIP Stack. The SIP Stack log quickly showed there was a problem communicating with the BES Collaboration Service. The error I was seeing in the Log Analyzer was SIPPROXY_E_CONNECTION_FAILED.

Then I remembered, OCS 2007 R2 has problems running on Server 2008 R2! Our brand new BES was running on Server 2008 R2 no less. I quickly searched my bookmarks for all those KB articles I had saved knowing I would need them again one day. The first one that everyone should review is the OCS 2007 R2 on Server 2008 R2 Supportability document. In there it makes reference to requiring a hot fix for Windows. This is not required if you're running Server 2008 R2 with Service Pack 1 on your BES server. Next, you need to update the OCS 2007 R2 components on the server. I suggest using the ServerUpdateInstaller package which can be found here. It will automatically detect which updates you need, download them and install them.

After all this, Lync/Enterprise IM on the Blackberry connectivity worked flawlessly. One last thing, if you need the Enterprise IM client for your Blackberry, grab it from RIM here. Enjoy your brand new Lync connectivity!

Can't map profile properties to AD fields in SharePoint? Read this!

If you've come across the error below, you are no doubt wondering what it actually means and more importantly how to fix it. Don't worry; you aren't alone.

Note: The selection of directory service properties may be disabled if the shared service provider is in an untrusted domain or if profile import is not configured.

Note: The selection of directory service properties is disabled because the portal is in an untrusted domain or no directory service import is configured yet.

Security Note: If you are using a high privilege account to import, you will be able to read and import directory attributes that are not normally accessible by users.

This one took me a while to figure out. The fix was rather simple in my case. It was a simple mismatch in Import Connections under the SSP User Profiles and Properties section. One of the connections was named after the NetBIOS name of the domain instead of the FQDN of the domain.

For example, the original connection was named domain when the domain's fully qualified name was users.domain.com. I created a new connection and named it users.domain.com and deleted the connection called domain. This was all done in the SSP's User Profiles and Properties section under Import Connections.

Once I created a new connection named after the domain's FQDN SharePoint decided it would let me map Active Directory fields to user profile fields.

All is well in the world again and I can continue with my late night work.

WinHTTP, .net, IE and Proxy Server Fun

Today, I was working on finalizing a solution for proxy auto configuration for the company I work for. The script that I had worked great with Firefox and Internet Explorer 6 and up. I found out quickly however, it did not work with WinHTTP or .net automatic proxy configuration. Anything dependent on either one of those got a proxy or went directly to the resource when it shouldn't have. Of course, this wouldn't fly.

After many hours of trial and error I came to the conclusion that WinHTTP and .net behave differently from their browser counterparts in a very significant way. When executing the script in a PAC file, browsers do not need to have the host wrapped in the dnsResolve function. WinHTTP and .net do need this however in order to properly determine when to use a proxy server.

Here is original proxy script I had that worked only with browsers:

function FindProxyForURL(url, host)

{

var myIPAddr = myIpAddress();

// Bypass proxy settings for internal domains and private IP ranges

if (isInNet(host, "10.0.0.0", "255.0.0.0") ||

isInNet(host, "192.168.0.0", "255.255.0.0") ||

isInNet(host, "172.16.0.0", "255.240.0.0") ||

isInNet(host, "127.0.0.1", "255.255.255.255") ||

isPlainHostName(host) ||

dnsDomainIs(host, ".domain-one.example.com") ||

dnsDomainIs(host, ".domain-two.example.com") ||

dnsDomainIs(host, ".domain-three.example.com") ||

dnsDomainIs(host, ".domain-four.example.com"))

{

return "DIRECT";

}

// Location 1 - Use Proxy server first then use direct if necessary

else if (isInNet(myIPAddr, "10.1.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.2.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.3.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.4.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.5.0.0", "255.255.0.0") )

{

return "PROXY PROXYSERV1:8080; DIRECT";

}

// Location 2 - Use Proxy server first then use direct if necessary

else if (isInNet(myIPAddr, "10.6.0.0", "255.255.0.0"))

{

return "PROXY PROXYSERV2:8080; DIRECT";

}

// Location 3 - Use Proxy server first then use direct if necessary

else if (isInNet(myIPAddr, "10.7.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.8.0.0", "255.255.0.0"))

{

return "PROXY PROXYSERV3:8080; DIRECT";

}

// Catch all for locations without proxy servers

else

{

return "DIRECT";

}

}

Here is the final PAC file that works with browsers, WinHTTP and .net:

function FindProxyForURL(url, host)

{

var ipAddr = dnsResolve (host);

var myIPAddr = myIpAddress();

// Bypass proxy settings for internal domains and private IP ranges

if (isInNet(ipAddr, "10.0.0.0", "255.0.0.0") ||

isInNet(ipAddr, "192.168.0.0", "255.255.0.0") ||

isInNet(ipAddr, "172.16.0.0", "255.240.0.0") ||

isInNet(ipAddr, "127.0.0.1", "255.255.255.255") ||

isPlainHostName(host) ||

dnsDomainIs(host, ".domain-one.example.com") ||

dnsDomainIs(host, ".domain-two.example.com") ||

dnsDomainIs(host, ".domain-three.example.com") ||

dnsDomainIs(host, ".domain-four.example.com"))

{

return "DIRECT";

}

// Location 1 - Use Proxy server first then use direct if necessary

else if (isInNet(myIPAddr, "10.1.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.2.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.3.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.4.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.5.0.0", "255.255.0.0") )

{

return "PROXY PROXYSERV1:8080; DIRECT";

}

// Location 2 - Use Proxy server first then use direct if necessary

else if (isInNet(myIPAddr, "10.6.0.0", "255.255.0.0"))

{

return "PROXY PROXYSERV2:8080; DIRECT";

}

// Location 3 - Use Proxy server first then use direct if necessary

else if (isInNet(myIPAddr, "10.7.0.0", "255.255.0.0") ||

isInNet(myIPAddr, "10.8.0.0", "255.255.0.0"))

{

return "PROXY PROXYSERV3:8080; DIRECT";

}

// Catch all for locations without proxy servers

else

{

return "DIRECT";

}

}

The differences are subtle but ever so important while implementing a proxy server auto configuration solution. Ensuring that WinHTTP and .net work like the browser should help ensure you don't get caught with servers/services and even client applications improperly using a proxy server. Of course with servers, the best option is to configure the WinHTTP options manually. This prevents the service from taking the performance penalty associated with automatic proxy discovery.

To manually configure the WinHTTP proxy server on computer you can either use proxycfg.exe or my preferred method of netsh. To set the proxy server and exclusions with netsh you can run the following command from the command prompt.

netsh winhttp set proxy proxyserver:8080 "<local>;server.domain.example.com"

The <local> entry tells WinHTTP to bypass the proxy for servers which use a relative name. Don't forget to run that command prompt as an administrator on Vista/7/2008/2008 R2 machines or you will get an access denied error.

If you ever need to clear out the WinHTTP proxy information you can run this command (again, as an administrator):

netsh winhttp reset proxy

And thus concludes my proxy server auto configuration odyssey.