Aimless Ramblings from a Blithering Lunatic . . .

Local access to your SharePoint 3.0 site

cgross — Wed, 09 Dec 2009 06:58:01 GMT

OK – just a quick poll . . . Raise your hand if you’ve seen this:

You install Windows SharePoint Services 3.0 (either on a Windows 2003 or 2008 server) and create a new web app & site collection. While the site works great for all of your local clients, and even works externally – you can’t access the site from the server it is running on. Specifically – when you try to browse to the site on the local server, you get prompted for credentials 3 times before getting a generic 401 unauthorized error.

I’ll admit I have been seeing this for quite some time, but have always been too busy to track down the cause, especially since the easy workaround is to just access the site from another machine. Well, I finally did some digging and was able to identify the cause & the solution. This is actually caused by a failing loopback check – which is the exact same scenario that causes the infamous 2436 Gatherer errors for our companyweb in SBS 2008. And to keep things consistent – the exact same fix for the 2436 errors will fix our inability to access a WSS 3.0 site on the local server it’s running on.

You can find the specific steps on the SBS support blog:

http://blogs.technet.com/sbs/archive/2009/05/07/event-2436-for-sharepoint-services-3-search.aspx

Just add the URL of your site to the BackConnectionHostNames registry entry, run an iisreset and you’ll be good to go!

Where did it all go?

cgross — Fri, 04 Dec 2009 17:47:39 GMT

Ok – so I have a somewhat funny story to share . . . About a week ago, I received a monitoring alert via Kaseya that free space on the C: drive on my SBS 2008 server was getting low. I logged in to the server, opened My Computer and it showed that I was using 73 GB of my 80GB C: partition. So I downloaded TreeSize Free to see what was taking up all of the space. The problem I ran in to was that TreeSize was showing that I was only using 31.9 GB of space on my C: – no where near the 73 GB that Windows was reporting. TreeSize did indicate that it couldn’t access the C:\PerfLogs or C:\System Volume Information. I manually verified the PerfLogs folder was empty, and I did find that I had approx 8GB in ShadowCopies for the C: drive that I didn’t need since all of my critical shares had been moved to a different partition, so I disabled ShadowCopies on the C: drive, but that still left me with a 33GB discrepancy between Windows & TreeSize . . .

At this point, I am going to share two crucial bits of information: 1) This is the first time I’ve dealt with low-drive space on a Windows 2008 box. 2) I’ve been using TreeSize for years, and by force of habit, I always open My Computer, right-click on the drive I want to scan and launch TreeSize from the context menu. So can you see where I went wrong?

Yep – I was quietly bitten by UAC in SBS 2008. By launching TreeSize in my normal fashion, TreeSize was not running with elevated permissions and was unable to access all of the directories on the drive, many of which were several layers deep. Interestingly enough, TreeSize Free didn’t throw any errors when it encountered a directory it couldn’t access. Once I launched TreeSize Free from the Start Menu with elevated permissions, it was able to scan the full drive and show me my smoking gun – 27GB of IIS logs for the WSUS Administration site collected over the last 12 months. So after cleaning up my unnecessary Shadow Copies & purging old IIS logs, I’m back to 41.2 GB (51.5%) free space on my C: drive . . .

Group Policy Loopback Processing

cgross — Mon, 12 Oct 2009 18:33:00 GMT

Subtitled - “Wow, I learned something new today!”

So in the Third Tier support queue today, Jon posed an interesting question:

How do I exclude Folder Redirection from applying to one domain-joined laptop that is out of the office & disconnected from the domain most of the time?

To revisit Group Policy basics for everyone – GPOs can apply to either computer accounts or user accounts. GPOs that apply to computer accounts are processed when computers boot up (we’ve all seen the “Applying Computer Settings” message during startup), and GPOs that apply to user accounts are processed during login. Obviously, Folder Redirection is a user setting in Group Policies, and GPOs don’t have the same targeting options that Group Policy Preferences do. So how do we have different GP user settings implemented when users log in to specific machines? Via User Group Policy loopback processing, of course . . .

So what is User Group Policy loopback processing? It is a Group Policy setting that applies to Computer accounts. When enabled, it effectively tells a computer to process User Settings in GPOs that apply to the computer account whenever a user logs on to that computer. As a result, we are able to define user GP settings in a GPO applied to computer accounts instead of user accounts.

User Group Policy loopback processing can be enabled in one of two modes: merge or replace. In merge mode, both GPOs applying to the user account and GPOs applying to the computer account are processed when a user logs in. GPOs that apply to the computer account are processed second and therefore take precedence – if a setting is defined in both the GPO(s) applying to the user account, and the GPO(s) applying to the computer account, the setting in the GPO(s) applying to the computer account will be enforced. With the replace mode, GPOs applying to the user account are not processed – only the GPOs applying to the computer account are applied.

In Jon’s specific case, he wanted to exclude Folder Redirection for one remote laptop. The folder redirection settings in Group Policies do not have a “disable” option – only “Not Configured” or enabled via the “Basic” or “Advanced” modes. Since there isn’t an option to explicitly disable Folder Redirection, the merge option would not meet Jon’s needs, since the user GPOs would be applied and Folder Redirection would remain enabled on the laptop. By using the “Replace” mode and not defining Folder Redirection in the GPO that applies to the computer account, Jon is able to achieve his desired result.

Take-aways on User Group Policy Loopback Processing:

This is a COMPUTER setting, which is found under Computer Configuration | Administrative Templates | System | Group Policy | User Group Policy Loopback Processing Mode
You want to create a new OU in AD that is dedicated to computer accounts that will have loopback processing enabled.
Create a new GPO in your new OU to enable User Group Policy Loopback Processing and set the appropriate mode (merge / replace).
You will define the user settings you want to apply to the loopback-enabled PCs via GPOs in this same new OU. You can define these settings either in the same GPO where you enabled the User Group Policy Loopback Processing setting, or you create another new GPO in the same OU for your user settings.
Remember that when using the REPLACE mode, none of your other user GPOs will be applied when a user logs in to a machine that has loopback processing enabled. ONLY the user settings that are defined in the GPOs that apply to that machine will be applied.

Killing off ISA

cgross — Mon, 12 Oct 2009 04:31:08 GMT

Earlier today Susan blogged about upgrade season in her office, and getting ready to migrate from SBS 2003 to 2008. In that post, she talked about uninstalling ISA and mentioned a post that Kevin has on that subject. I thought I’d take a moment to expand a little bit on Kevin’s post and add a few thoughts from my own battle scars with removing ISA.

First and foremost – Kevin mentions removing the ISA firewall client from all of your PCs before you remove ISA from the server. I cannot overstate how crucial this step is. The ISA 2004 firewall client uninstaller wants access to the original installation MSI, which lives in a share on your SBS box. This share is actually the Clients folder in the ISA installation directory. So what happens when you remove ISA from your SBS? You guessed it – the mspclnt share with the firewall client installation files is removed, which means any firewall clients still installed on PCs are not going to be happy when you try to remove them and they can’t find the MSI.

Since the Clients folder under the ISA installation folder is typically only about 5MB, I copy this folder to a safe spot on the server – usually my Tech directory where we keep various utilities and scripts. Here’s why – more and more, customers are backing up their workstations whether via Acronis / StorageCraft / Windows Home Server. We may find ourselves at a point in the not so distant future after removing ISA that we need to restore a PC from an image taken before ISA was removed, and need to remove the firewall client again. Or we may discover a forgotten PC / laptop that we missed removing the firewall client from. There’s all sorts of scenarios – but by keeping the Clients folder in-tact, we can share that out with the original mspclnt share name at any time and be able to uninstall the firewall client just like ISA was still installed on the server. Without the mspclnt share, you have a very VERY ugly path in front of you, and it is safe to say that you may end up facing the decision of living with the firewall client still on the machines, or wiping & re-installing the OS . . .

Second – Kevin also makes a brief mention about proxy settings. When you uninstall the firewall client from a PC, it will automatically disable proxy settings for the user account that is running the uninstall, but not for any other users on the machine. So if you have a PC that multiple users log in to, or if you are running a terminal server, be prepared for some proxy pain. I actually have a little VBScript that disables proxy settings for the current user by changing the value of the HKCU\Software\Microsoft\Windows\CurrentVersion\InternetSettings\ProxyEnable key from 1 to 0. I modify my login script to call the VBScript, in effect ensuring proxy gets disabled for each user when they log in to each machine.

The other aspect with proxy settings to keep in mind are your server-side applications. Unless you modified your ISA firewall policy to allow unauthenticated outbound http access from the server itself, you most likely specified proxy information for apps like Trend Micro’s Worry-Free Business Security or even WSUS – so that they can download their updates automatically. After removing ISA, you no longer have a proxy server, which means apps configured to use a proxy aren’t going to be able to get out to the internet. As a result, you stop getting automatic updates for things like A/V. So you will need to manually update the connection settings in these apps to remove the proxy settings previously defined.

So – here’s my quick checklist for removing ISA from your network & installing a hardware firewall:

Prep your hardware firewall in a lab setting. Enter in all public IP info, disable DHCP, and create all of our inbound rules. It’s best to do this while ISA is still installed & working, so you can refer to the rules in ISA to make sure you don’t miss any necessary inbound rules for your environment.
Backup your ISA configuration. While we’re moving away from ISA permanently, if we do encounter an issue with the new hardware solution where something isn’t working that was working with ISA, the ISA backup is an XML file that is relatively easy to read to see what rules you had and what they did without having to reinstall & restore ISA on your SBS.
Open up your outbound access in ISA by creating the proverbial ALL/ALL/ALL rule. In other words, create a new access rule in ISA allowing All outbound traffic via all protocols for all users/computers. Much of the internet access in ISA on SBS is dependent on users being members of the Internet Users security group. The firewall client on the PCs is what actually passes user info to the ISA server so it can check group membership. Once we remove the firewall client from PCs, ISA isn’t going to be getting user info and some stuff that worked before isn’t going to work now. If you only have 5 PCs and are moving from ISA to your hardware firewall on a Sunday when no one is working, you might be able to skip this step. But if you have a larger number of PCs, etc. this helps to insure you don’t disrupt users’ internet access too much while removing the firewall client . . .
In my case, I update my domain login script to call my DisableProxy.vbs script at this point.
Uninstall the firewall client from ALL PCs. Again – see my notes above. Your life will be MUCH simpler if you insure the firewall client is completely removed from all PCs before removing ISA from your server.
Copy the contents of the mspclnt share (%programfiles%\Microsoft ISA Server\Clients by default) to a safe location on the server, and plan to keep this folder safe for some time
Follow Kevin’s steps 3-9 to remove ISA from the server.
When you re-run the CEICW, it should automatically update the DHCP scope option on the server to use the internal IP of the new hardware firewall as the default gateway setting. If you have any devices that are using static IP addresses, you will need to manually update those with the new gateway. (HINT: Take a few extra minutes to create DHCP reservations for each device using a static IP, and change those devices to DHCP – so if you have another network reconfiguration in the future, all you have to do is reboot those devices instead of reconfigure . For all of your other DHCP devices, you will want to run an ipconfig /release followed by an ipconfig /renew to update their IP settings so they pull the new gateway, or you can reboot them as well. HINT 2 – PSTools are your friend. Create a batch file with the two ipconfig commands, and use PSExec to push & execute the batch file on all machines in the domain from the server. 5 minutes tops to update the IPConfig on all domain machines (that are online) instead of sneakernetting . . .
ALSO – if you followed Jim Harrison’s steps to configure auto-detection of proxy settings on your SBS LAN, you want to remove the wpad A record from your internal AD domain forward lookup zone in DNS – otherwise you may have devices pulling proxy settings for pointing to your non-existent proxy server via auto-detect.

So that’s my addendum to Kevin’s excellent post.

P.S. . . . and if you haven’t decided on a hardware firewall yet, I highly recommend Calyptix devices. These are the standard devices we are implementing when migrating customers to SBS 2008.

The Savvy-Tech’s Hardware-Independent-Restore

cgross — Wed, 09 Sep 2009 00:03:55 GMT

Ok, so I thought I’d share a real-world support scenario that happened to me today:

So I have a new contract customer I just signed a couple weeks ago, and they went live as of 9/1. I was doing various maintenance tasks on their network over the weekend, removing unnecessary apps from PCs to improve performance, getting patches installed, etc. So about the only thing that was left last night was patching their Windows 2003 terminal server. So I push the patches out via Kaseya, patches install successfully, the server initiates a reboot – but never comes back. Now, I’ve been doing remote patching / reboots for years now, and this has only ever happened a handful of times.

I log in to their SBS and attempt to ping the TS – no response. The TS is a whitebox server that is about 4 years old and doesn’t have a remote access card or IP-KVM connected. The client is in bed, and not having the TS really isn’t going to be an issue until their approx half-dozen remote users try to access Great Plains in the morning. So I didn’t bother calling to wake anyone up – instead, I more or less surprised the VP when I walked in at 7:30 this morning to address a problem they didn’t know they had yet.

Short story was that the server was pretty much on its deathbed – the alarm LED on the case was coming on whenever the processor tried to do anything. It took 5 attempts before I was able to get the server to boot, and when I did get logged in the CPU was grinding constantly with the error LED lit, but looking at the task manager I didn’t see anything out of the ordinary, besides the fact that the system was so slow it was virtually unusable for one user at the console, let alone a half-dozen plus remote TS users trying to use Great Plains. Quick diagnosis & gut instinct told me this was a hardware issue. Being a 4-year old whitebox, it was long out of warranty. I knew the server just needed replaced, but the remote users couldn’t wait a week to 10 days for me to get approval, get a box ordered from Dell, and get it installed. Additionally, for the state of the machine, it would probably take days to get an image-based backup using Shadow Protect, since this is a new customer and they aren’t backing up the TS since there’s no data on it.

SO – I ran back to my office and grabbed a spare PC I use for random stuff on my bench (Acer - about 3 yrs old, but has a dual-core Pentium CPU @ 2.8 GHz & has been upgraded to 2GB RAM). I also grabbed my old Adaptec 1205SA PCI SATA host controller off the shelf and returned to the client.

The TS in question was running a RAID 1 array using an on-board SATA RAID controller. I shut down the TS, and installed the Adaptec SATA controller in an open PCI slot, then after 4 tries the server finally booted again. I logged in, the OS found the Adaptec SATA controller & I installed drivers from my thumb drive. Once the driver installation completed successfully, I shut down the TS again.

I removed the Adaptec SATA controller & drive 0 from the TS. I installed the Adaptec SATA controller in the Acer PC, inserted & connected drive 0 from the TS to the Adaptec SATA controller, then disconnected the existing SATA hdd in the PC. I powered-on the PC, and since drive 0 was connected to the Adaptec SATA controller, AND the Win2k3 OS on drive 0 already had drivers for that controller installed, the Win2k3 TS OS booted successfully in (almost) completely different hardware. On the first login, the OS detected the various new hardware (on-board boot controller, DVD drive, on-board NIC, etc.). Once drivers for new hardware were installed & onboard NIC configured, I powered down the Acer PC, removed the Adaptec SATA controller card, & connected drive 0 to the on-board primary SATA port. Powered on the PC – the Win2k3 OS again booted successfully, and we verified that remote users were able to successfully log in and launch Great Plains.

Obviously, using a 3-yr old desktop PC as a terminal server is not a long-term solution. But – this minimized downtime for the remote users (having them all online before noon), and provided both myself & the customer with valuable breathing room / time to resolve the root issue and get the ball rolling on replacing this server. And given the small number of users and basic Dynamics GP use, the performance of this temporary hardware is more than sufficient for the remote users (and beats the alternative )

And yes, there is more than one way to skin a cat – and multiple ways this problem could have been addressed. In this particular situation, I felt this was the best approach to get to a working system in the least amount of time possible, considering the severe instability of the original hardware, the lack of an existing image backup of the TS, and the fact that I could easily break the mirror to run off a single HDD from the server.

Migrating your SharePoint blog

cgross — Sat, 05 Sep 2009 17:28:22 GMT

As some of you may know, I assist Susan with administering & maintaining the blogs here at msmvps.com. For various reasons, over the past few months I have become familiar with various approaches to blog migrations – most notably the BlogML project. As a result, I’ve sort of become the neighborhood go-to guy for moving blogs, including assisting Steve Riley with his move from msinfluentials.com to wordpress.com

A couple weeks ago I was presented with an intriguing request / challenge. My friend Wayne Small over at sbsfaq.com had been running his site and his blog on SharePoint for several years, but was now in the process of moving everything over to a single Word Press site, and wanted to migrate his content from his SharePoint blog. The challenge wasn’t so much getting the content in to Word Press, since there are several importers available, including a BlogML importer. The problem was getting the content out of SharePoint 3.0. BlogML exporters for most platforms are web based, allowing you to initiate the export from within the blog platform, and download the resulting export file. While I have coding experience, I don’t have any experience building add-ins for SharePoint and wasn’t about to open that can of worms, so I decided for a different approach.

For those of you who don’t know, there is rather impressive integration between SharePoint 3.0 & Access 2007, so I opted to use Access to extract the information out of Wayne’s old SharePoint blog. This approach actually gave me more flexibility in meeting the various requirements:

Where the SharePoint blog used Categories, Wayne wanted to use Tags in Word Press.
We wanted to migrate all content – posts, comments, & embedded content (images in posts, etc.)

Moving categories to tags seemed simple enough, however I discovered that the the current 2.0 iteration of BlogML doesn’t support tags (which admittedly surprised me). As a result, Aaron Lerch’s BlogML import class for Word Press did not support tags either. Scoring the web, I found that Wayne John had updated Aaron’s BlogML import class to allow for importing tags from Blog Engine exports. I did a quick & dirty install of Blog Engine on my sandbox server so I could examine its default BlogML export so I could match how it tagged its XML to identify post tags.

One of the major behind-the-scenes differences between SharePoint blogs & Word Press is how embedded content is stored. When you are composing posts using an offline editor such as Windows Live Writer, inserted images are stored differently in each platform when the post is uploaded & published. Word Press stores the images in the file system on the site, whereas SharePoint stores the images in the database as attachments to the post record. Luckily for us, Access 2007 can handle attachments on SharePoint lists natively. In early test runs, I found that there was some duplication in image names between various posts in Wayne’s blog (especially capture.png). As a result, I decided to save the attachments for each SharePoint post to a different folder to avoid name collision issues.

So – how does the final solution look?

I created a new Access 2007 database, and used the External Data functionality to link to the Posts, Comments, & Categories lists on the SharePoint blog site.
I created a simple form that allowed me to enter the path & filename I wanted for the resulting BlogML export file, as well as a path to where I wanted the embedded images from the SharePoint blog stored. Obviously, the form contained a Start button as well . . .
When the start button was clicked, the code behind the button did all the heavy lifting:

It creates the BlogML export file using the path / filename listed on the form, and writes the various header information.
We open a new recordset containing the Posts table.

We call a helper function to format the post published date how the XML file wants it.
We open a second recordset that contains the attachments for the current post we are processing
If the current post has attachments, then:

We save each attachment to the local file system, using the patch specified on the main form. To prevent filename collision, we create a new subfolder for each post, using SharePoint’s numeric post ID as the folder name. (So if we listed C:\export as the folder we wanted to save embedded images to on the main form, we would end up with something like C:\export\<post_id>\capture.png)
For each attachment, we populate the <attachment /> node of the BlogML output.
We parse the body of the current post and replace every path we find pointing to the old attachment path with the new attachment path. E.g., links to embedded content in the SharePoint blog are referenced via “/Lists/Posts/Attachments/<post_ID>/<filename>” where once we import content in to Word Press, the path will be something like “/wp-content/uploads/<post_ID>/<filename>” By updating the relative paths to our embedded content during the export, we can better insure that our embedded content will transfer seamlessly. This isn’t the case with most BlogML exports, because they are simply exporting the content, not updating embedded links to match the target platform.
We cycle through and repeat for each attachment for the current post.

We write the post content to the Output file
For each category listed in the Posts recordset, we write a <Tag /> to the output file (to match Wayne’s requirements).
We open a third recordset which contains all of the comments for the current post. If the current post has comments, then:

We call a helper function to format the comment date how the XML file wants it.
We write the current comment to the output file
We cycle through & repeat for each remaining comment for the current post.

We cycle through and repeat for each post

We write the closing tags to the output file and complete the process.

So in the end, we have one BlogML.xml file with all of the blog content (posts, comments, categories, tags, etc.), and a folder that contains all of the exported embedded images from the SharePoint blog posts (in separate sub-folders by post ID).

At this point, Wayne simply had to copy the embedded images subfolders to his /wp-content/uploads folder for his site, then run the BlogML import process to import the content generated. Voila!

For example:

Post on SharePoint blog: SBS 2008 R2 I want it now!

Migrated post on WordPress blog: SBS 2008 R2 I want it now!

Notice the embedded image is displayed as expected – and if you look at the image properties on the Word Press post, you’ll see it is referencing the relative path to the image on the Word Press site. In addition, the original post date & author info has been maintained, as have all comments, with their original comment dates & author info.

One caveat that is important to share – when I was first starting to test the import process, the BlogML import in Word Press was failing with an error that invalid characters were encountered on line X at column Y. However, opening the BlogML export file in notepad, wordpad, or IE – I couldn’t see anything that appeared to be an invalid character. Finally, opening the BlogML output file in Visual Studio 2008 allowed me to see the invalid characters, and I was able to remove them with a simple find/replace in Visual Studio, after which the import process in Word Press completed successfully. I’m not sure what caused these characters to be present in the first place – perhaps the authoring tool Wayne used, or perhaps something in the export process, pulling from SharePoint to Access to text.

But anyway, that was one of my recent side-projects. Let me know what you think – the Access database I used was rather rough around the edges and relied on a number of assumptions I was able to make which resulted in certain options being hard-coded. If there is enough interest, I’ll polish it up a bit and post it for others to use to export their SharePoint blogs to BlogML.

Saving me from myself…

cgross — Fri, 07 Aug 2009 23:33:12 GMT

So I just had an e-mail come through from twitter telling me that I had a new follower – unfortunately, it appears to be a twitter bot (you know, the personal picture of a scantily-clad blonde, who is following 1300 people, but has zero tweets & zero followers?). So I decided to log on to twitter’s website and clean up my followers since I was pretty sure there were one or two others that had started following me this week. As I was waiting for the page to load, I received an interesting pop-up:

I’m running Trend Micro’s Worry-Free Business Security 6.0 on my SBS 2008 network, and it blocked my access. I found this rather interesting, because I know that I only have Trend doing basic web-filtering (e.g. only blocking known malicious sites). I moved the pop-up window out of the way so I could see the page in the browser – which also showed the content was blocked:

However, the Page Blocked message in the browser helped me realize what happened – what I didn’t pick up from the pop-up window. I had completely fat-fingered the URL and misspelled the domain name, only including 1 “t” in twitter instead of 2. And obviously, this site must have some malicious content. So a big kudos to Trend’s WFBS for protecting yet another user from themselves

External Links in Companyweb E-mail Alerts

cgross — Sun, 02 Aug 2009 17:39:51 GMT

A while back, someone in the SBS 2008 newsgroup had a good question. Short story is that they are making extensive use of their companyweb, including content approval in some document libraries. They have configured email alerts on these libraries, so approvers are notified when new documents are added and waiting approval. However, a few of these approvers travelled regularly, and were often out of the office. When they received new email alerts from their companyweb, the embedded links all pointed to http://companyweb/… The obvious problem was that if they were working from their laptop with Outlook RPC over HTTPS at say an airport, Starbucks, or wherever then the links in the alert email wouldn’t work (since http://companyweb is only resolvable on the LAN). The poster in the newsgroup asked where SharePoint stored the URL so he could edit it.

The beauty with this question is just how simple the solution is. SharePoint 3.0 supports a single web application being accessible via different URLs, with the different URLs being in different security zones. This is evidenced by your companyweb in SBS 2008 being accessible via both http://companyweb (intranet zone) and https://remote.yourcompany.com:987 (default zone). When a user is creating alerts on a SharePoint site, SharePoint is smart enough to take note of which URL the user is using to access the SharePoint web application when they create the alert. As a result, links in alert emails will include the base URL that was used to access the SharePoint site when the alert was created. SO – if you browse to http://companyweb and create an alert on a list library, all emails you receive for that alert will have links that point back to http://companyweb. On the other hand, if you browse out to https://remote.yourcompany.com:987 and create an alert on a different list or library, all emails you receive for this alert will have links that point back to https://remote.yourcompany.com:987.

SO – if you have users who are regularly out of the office, rely on alerts from your SharePoint site and want to be able to use the links in the alert emails, make sure those users browse to the public URL for your companyweb when they create their alerts.

Optimizing Companyweb Search Results in SBS 2008

cgross — Sat, 13 Jun 2009 04:27:38 GMT

I’ll admit this post is long overdue. I’m sitting here staging a new server for a client and just finished running through these steps on their server, so I figured now was a good time to post since the process is fresh in my head. Particularly, the task at hand is to configure companyweb on our SBS 2008 to properly index Office 2007 documents and PDF documents, so their contents will appear in SharePoint search results.

Yes, you read the correctly. Small Business Server 2008’s companyweb does not index Office 2007 documents out of the box – I kid you not . . .

Luckily, getting Office 2007 documents to show up in companyweb search results is simple enough, all you have to do is download and install the Office 2007 iFilter from Microsoft on your SBS server. When downloading, obviously be sure to download the 64-bit version of the filter pack.

After installing the Office 2007 iFilter, we need to install a PDF iFilter as well. Luckily, Adobe has released a 64-bit version of their PDF iFilter, which you can download here. Unlike the Microsoft Filter Pack, there is some manual configuration to complete after we install the Adobe PDF iFilter:

On your SBS, run regedit and navigate to the following registry key:
HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications\<GUID>\Gather\Search\Extensions\ExtensionList\
Right-click on the ExtensionList key and select New –> String Value
Enter 38 for the new string value and hit Enter
Double-click on the 38 string value you just created to edit its value. In the Value Data box that opens, type pdf then click OK.
Locate the HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf key and verify it contains the following registry entry:

Name: (Default)
Type: REG_SZ
Data: {E8978DA6-047F-4E3D-9C78-CDBE46041603}

You will most likely need to edit this entry so its value matches the GUID listed above.
Locate the HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\Filters\.pdf subkey and verify it contains the following entries:
1. Name: (Default)
  Type: REG_SZ
  Data: (value not set)
2. Name: Extension
  Type: REG_SZ
  Data: pdf
3. Name: FileTypeBucket
  Type: REG_DWORD
  Data: 0x00000001 (1)
4. Name: MimeTypes
  Type: REG_SZ
  Data: application/pdf

That completes the installation / configuration of our iFilters. If you haven’t already fixed the SharePoint Gatherer 2436 errors on your SBS yet, be sure to do so now. (Check out the Official SBS blog’s post on the topic).

So, once you have your iFilters installed & configured, and you have your SharePoint Gatherer 2436 errors resolved, we just want to bounce IIS then force SharePoint to start a full reindex of your companyweb site to index any Office 2007 and PDF files you have previously uploaded:

Open a command prompt (as Administrator) and run an iisreset
After the iisreset completes, change your working directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin
Stop the SharePoint search indexing process by running this command: stsadm –o spsearch –action fullcrawlstop
Once that command completes successfully, start a reindex of your WSS 3.0 site(s) by running this command: stsadm –o spsearch –action fullcrawlstart

Once the fullcrawlstart command completes successfully, SharePoint will start reindexing your site(s) and you should start seeing search results in companyweb within a few minutes, although it may take longer for the site to be fully indexed depending on how much content you have in your site.

Happy searching!

SBS 2008 + loopback check + remote.company.com = SharePoint 2436 errors

cgross — Thu, 07 May 2009 19:43:00 GMT

OK gang -

The SBS team has blogged explaining where our 2436 errors come from on SBS 2008. The short story is that SBS is thinking it is protecting itself. Recommended solution is to edit the registry to add the public URL for your companyweb (e.g. remote.company.com) to the BackConnectionHostNames, allowing that URL to bypass your SBS server’s loopback check.

Google searches will result in a multitude of work-arounds different people have posted, most of them you do not want to implement including:

Disabling the loopback check all together.
Tweaking the Alternate Access Mappings in SharePoint (unless you need to for other legitimate reasons – not the 2436 error)
Changing your companyweb’s security zones in SharePoint (remote.company.com should be the Default zone, with companyweb in the Intranet zone).

If you're like me and subscribe to the idea of least privilege access, you can still update the SharePoint search configuration as mentioned in my previous post. Most built-in accounts (e.g. NETWORK SERVICE, LOCAL SYSTEM, etc.) have more permissions than required to perform SharePoint search functions. Creating standard user accounts to do the SharePoint Search work follows the general best practices of least-privilege access. While this follows SharePoint best practices in not using built-in accounts for the SharePoint search service or search content access accounts, it is important to note that editing the SharePoint search configuration on your SBS 2008 has not been tested by Microsoft and therefore is not officially supported. This doesn't mean it won't work (my SBS 2008 boxes are running this configuration without issue so far) - it just means that if it doesn't work, Microsoft isn't going to support the configuration. So if you want to keep in the fully supported realm, leave the SharePoint search configuration as-is.

WOW

cgross — Mon, 30 Mar 2009 18:28:12 GMT

I have a tendency to be a bit behind the curve on some things. For example, just last week I finally got a chance to load up Windows 7 for the first time. My initial impression after a few days: Wow. No really . . . WOW

I decided to sacrifice my Vista Ultimate box for the test. Being a glutton for punishment, I did try an in-place upgrade of Windows Vista Ultimate (x86) to Windows 7. The upgrade took an exceptionally long time, and ended up hanging on the last stage of the install as it was bringing back in my settings from my Vista installation. I let it sit for 3hrs at that spot, noticing that the file count was not changing. At that point, I cancelled the process and decided to do a clean install. Since this is beta code of Windows 7, I’m not overly concerned about the upgrade failing.

First impression with the clean install was that it completed much faster than I remember a clean install of Windows Vista taking.

So the install finished, I tweaked my SBS 2008 to allow me to connect Windows 7 using SBS 2008’s connect computer wizard, and joined to the domain. I noticed that the SBS connect computer wizard was unable to rename the Windows 7 PC – again, being beta code I’m not overly concerned – especially since all other aspects of the wizard completed successfully and joined the machine to the domain.

I installed my normal applications: the Trend WFBS client, Office 2007 Ultimate, Peachtree 2008 Complete, Quicken 2007 Deluxe, Adobe Acrobat 8.0 Pro, Firefox, Windows Live utilities (Mail, Messenger, Photo Gallery, & Writer), and my Zune application. All of them installed and have so far worked flawlessly. The only issue I have encountered is with accessing AutoTask via IE8 in Windows 7 – the sub-toobar in the main application doesn’t fully display, and a toolbar in a few of the grid lists doesn’t display properly – Luckily AutoTask is still usable despite this. The Windows 7 beta build that I’m running (7000) does not include the final IE8 bits, and IE8 has some unique features only available in Windows 7, so it’s not surprising that an extensive web application such as AutoTask might have a few unexpected behaviors in a beta browser on a beta OS

So the big question in my mind before installing Windows 7 was how was it going to perform? Especially since my test machine is about 3 years old and has modest specs:

Single-core Intel P4 processor @ 3.6 GHz
120 GB 7200 RPM SATA HDD
nVidia GeForce FX 5500 AGP video
1GB DDR RAM @ 400 mHz

Yes – you read that right. I was running Vista Ultimate on a PC with only 1GB RAM. I told you I was a glutton for punishment . . . And I’ll be honest – Vista ran decently on this box after some tweaking. Startup & login was slow. I couldn’t run the Windows Sidebar without the experience being painfully slow. And even then, if I got multiple applications open, the system would slow down noticeably. It wasn’t un-usable, but the various wait times were definitely noticeable.

So how does Windows 7 compare? Wow. Windows 7 running on the same box is noticeably faster than Vista was. Obviously the Windows Sidebar is gone in Windows 7, with gadgets being directly integrated into the desktop. I’m running several gadgets in Windows 7, and my usual contingent of multiple applications, and the performance is noticeably better. Quite honestly, performance and responsiveness feels on par (if not a bit better) than XP Pro on this hardware. Obviously this is anecdotal – and I haven’t done any sort of benchmark testing – just user impression. Now admittedly there are a few spots where there is a noticeable delay – primarily opening Control Panel, and the Uninstall Program window. It does seem faster than Vista, but not as fast as the rest of the Windows 7 experience.

After several days, I find that I’m quickly adapting to the changes in Windows 7:

Customizable power button on the Start Menu. OK, this was a big annoyance for me in Vista. I never Shut Down my machines – I normally lock or log off. Now we can set the default action of the power button on the start menu. Yay!
Quick Launch is gone: Well, only sort of. The separate Quick Launch toolbar is gone, but we have the ability to pin items to the taskbar, which effecitvely gives us the same functionality of launching applications. The difference with pinning items to the taskbar is that the pinned items are not only shortcuts to launch those applications, but once launched the pinned item is the application on the taskbar.
Aero Peek: When similar application windows are grouped on the taskbar, you can hover your mouse of the application group on the taskbar and see previews of each window in the application group. BUT – if you hover over one of the previews, you can peek at that window – effectively all windows minimize to only show you the window you are peeking. Move your mouse away and you go right back to whatever active window you were working in. This ROCKS – being able to reference other applications / windows without clicking and without losing your cursor / focus in your current application. Another added bonus – if you have IE open with multiple tabs, you can actually peek at each individual tab – not just the current active tab in each IE window. NICE!
Show Desktop: Now instead of separate shortcut on the Quick Launch – we get a little slice to the far right of the task bar, just to the right of the clock. Not only does this give us better utilization of the taskbar real estate, but we can also peek the desktop by hovering over this slice as well. This is great when I want a quick glance at my calendar or weather gadgets.
Jump Lists. After only a few days, I’m wondering how I ever lived without jump lists . . . For example, the built-in Documents jump list can be customized to include multiple folders. I’m using folder redirection to my SBS, and I also have my user share on the SBS as well. When I open the documents jump list, it now shows me contents of both my redirected My Documents and my user share on my SBS – all in one view.
Taskbar context menus: Right-clicking on certain items in the taskbar gives you access to relevant items. For example, right-click on the Windows Explorer item, and you get a jump list showing your recent places. You can also pin folders / jump lists to this jump list to quick & easy access to common places. Also, right-clicking on the Internet Explorer taskbar item presents you with a jump list showing recent browsing history.

So far, the only hiccup I have ran in to is that for some reason I can’t seem to create a network location pointing to a SharePoint site or library. This isn’t a show stopper to prevent me from using Windows 7 – but something I’d like to figure out. Overall, my experience with Windows 7 has been positive enough that I decided to try loading Windows 7 on my trusty 4 year old Acer TravelMate C310 laptop as well. I had tried running Vista on this machine previously – but reverted back to XP shortly thereafter. With a mobile processor and 1 GB RAM, Vista just wasn’t usable on that machine – and I couldn’t get the Aero display to work with the built-in graphics. I did a clean install of Windows 7 on the laptop this weekend and again – WOW. The performance matches XP on the same hardware. The bulk of the hardware devices were detected automatically (although I did have to install Vista drivers for the Bluetooth adapter, card reader, and Intel 2200 b/g wireless adapter) – but that went off without a hitch. And surprisingly – the Aero display works as well!

I’ve also found blog posts here & here explaining some additional functionality, improvements, & usability enhancements that are coming with the RC release.

To summarize - I find that I’m actually excited about Windows 7 – in a way I wasn’t excited about Vista. Not only that, but I can see myself easily recommending this upgrade to clients still holding on to Windows XP . . .

SharePoint Search & Event ID 2436 errors in SBS 2008

cgross — Mon, 30 Mar 2009 00:30:00 GMT

*UPDATE: Still not why the steps below work on some boxes but not others. However, the SBS team just blogged about the implications of the Loopback Check registry key as well as the ability to register your public URL on your SBS box so that it bypasses the loopback check without having to completely disable the loopback check. I still recommend reconfiguring SharePoint Search as noted below in addition to registering your public URL to bypass the Loopback Check.

*UPDATE: We have confirmed that the steps below work on some SBS 2008 boxes, but not all installs. If these steps do not work, see Dan's entry in the Comment section about disabling the LoopBackCheck in the registry. Despite what you may see in other forums, SharePoint search will work just fine with https://remote.company.com being the Default security zone for your companyweb - you do not need to edit your alternate access mappings. Additionally, the SPContent account only needs to be a member of the domain users security group, and the SPSearch account only needs to be a member of the domain users and WSS_WPG security groups. SharePoint Central Administration will add the SPSearch user account to the WSS_WPG security group when search is configured per the steps below.

*Updated on 2009-03-29 at 9:45am CDT (GMT -5). Original post missed the steps of stopping the Search service before reconfiguring.

With Small Business Server 2008, SBS customers finally get Windows SharePoint Services 3.0 built-in to replace the SharePoint 2.0 companyweb included with SBS 2003. However, when you get your SBS 2008 box all set up and running, you may notice a few quirks when it comes to SharePoint search. Specifically,you are seeing 2436 errors in your Application event log:

Log Name:      Application
Source:        Windows SharePoint Services 3 Search
Date:          3/29/2009 4:20:05 PM
Event ID:      2436
Task Category: Gatherer
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      server.company.local
Description:
The start address <sts3s://remote.company.com:987/contentdbid={d4078aab-
ce82-4581-8d4f-973e1e6eac23}> cannot be crawled.

Context: Application 'Search index file on the search server', Catalog
'Search'

Details:
    Access is denied. Check that the Default Content Access Account
has access to this content, or add a crawl rule to crawl this content.
(0x80041205)
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
    <Provider Name="Windows SharePoint Services 3 Search" />
    <EventID Qualifiers="32768">2436</EventID>
    <Level>3</Level>
    <Task>3</Task>
    <Keywords>0x80000000000000</Keywords>
    <Channel>Application</Channel>
    <Computer>server.company.local</Computer>
    <Security />
</System>
<EventData>
    <Data>

Context: Application 'Search index file on the search server', Catalog
'Search'

Details:
    Access is denied. Check that the Default Content Access Account
has access to this content, or add a crawl rule to crawl this content.
(0x80041205)</Data>
    <Data>sts3s://remote.company.com:987/contentdbid={d4078aab-ce82-4581-
8d4f-973e1e6eac23}</Data>
</EventData>
</Event>

The issue here is that Windows SharePoint Services Search uses two separate accounts – one user account runs the search service, and the other user account is used to actually access the SharePoint content in order to index it. When configuring SharePoint Search, SharePoint Central Administration explicitly states that these accounts cannot be built-in accounts (such as LOCAL SYSTEM or NETWORK SERVICE). By default, SBS 2008 is using built-in windows accounts, which is resulting in this error being generated.

Luckily, this is easy to fix. The first thing we need to do is to create two new user accounts for SharePoint search to use. Personally, I do not create these accounts using the SBS add user wizard, because they will effectively be service accounts, so they do not need mailboxes, and we don’t need to see these accounts included in the User account list on the SBS console.

On your SBS, open Active Directory Users & Computers (Start –> Administrative Tools –> Active Directory Users & Computers.
Within ADU&C, navigate to the Organizational Unit where you want to create the new user accounts. (Personally, I create a new “Service Accounts” OU under <domain> –> My Business –> Users)
Right-click on the OU and select New –> User
On the first page of the new user window, enter the following info:
- First Name: SPSearch
- Last Name: <leave blank>
- Username: spsearch
Click Next.
Enter a strong password for the new account.
Uncheck the option “User must change password at next login”
Check the option “User cannot change password”
Check the option “Password never expires”
Click Next
Click Finish.
Repeat steps 3-11, using “SPContent” instead of “SPSearch” in step 4

We do not have to worry about granting any access or permissions to the two new accounts we created. After the accounts have been created, close Active Directory Users & Computers, then open SharePoint Central Administration (Start –> Administrative Tools –> SharePoint 3.0 Central Administration).

When SharePoint 3.0 Central Administration opens, go to the Operations tab.
Click on the “Services on Server” link
In the Action column, click the link to Stop the “Windows SharePoint Services Search” service.
- You will receive a warning that stopping the search service will remove existing indices. Click OK to acknowledge the warning.
When you return to the SharePoint Central Administration Operations tab, the Windows SharePoint Search Service will show as stopped. Click the link to Start the Windows SharePoint Services Search service. This will open the Search service configuration page.
In the Service Account section, select the “Configurable” option
1. For a username, enter <DOMAIN>\SPSearch (where <DOMAIN> is your AD domain).
2. For a password, enter the strong password you assigned to the SPSearch account.
In the Content Access Account section, select the “Configurable” option
1. For a username, enter <DOMAIN>\SPContent (where <DOMAIN> is your AD domain)
2. For a password, enter the strong password you assigned to the SPContent account.
In the Search Database section, change the database name by appending and underscore 1 (“_1”) to the database name.
- By default, the database name should be WSS_Search_[SERVERNAME], so we’re changing it to WSS_Search_[SERVERNAME]_1.
- Changing the name is necessary because the default database name already exists with search data. If we attempted to use the default database name, SharePoint would throw an error that the database contains user-defined schema and cannot be used. By changing the search database name on this configuration page, SharePoint Central Administration will create a new database using this name and configure search to use this new database. Since the new database is empty, we won’t encounter any errors.
Accept the remaining defaults and click the OK button.

After clicking OK, the settings should be applied and you should return to the “Services on Server” page in SharePoint Central Administration, and the Windows SharePoint Services Search” service should be listed as started.

Close SharePoint Central Administration and open the Services MMC (Start –> Administrative Tools –> Services). Restart the Windows SharePoint Services Search service. Verify that the Windows SharePoint Services Search service is configured to login with the SPSearch account you created.

Voila! Moving forward, you should not experience the 2436 error event in your Application Log.

Drive Mapping via Group Policy Preferences not working for Vista clients

cgross — Wed, 25 Mar 2009 22:59:45 GMT

Ok – so this has been bugging me for a while. One Vista machine on my SBS 2008 was not having mapped drives created via the Group Policy Preferences I had established. I could log in with the same user account on another Vista machine as well as two XP machines, and the drives were mapped as expected. I did some troubleshooting a while back, but didn’t spend a lot of time on it since it was an annoyance for me at best.

Well the condition has been fixed – thanks to a stellar find by Cliff Galiher in microsoft.public.windows.server.sbs:

After you turn on User Account Control in Windows Vista, programs may be unable to access some network locations
http://support.microsoft.com/kb/937624

I made the registry change indicated in that KB article, rebooted and voila! – my GPP drive mappings are working.

Migrating a WSS 3.0 Site to SBS 2008

cgross — Sun, 22 Mar 2009 23:38:51 GMT

Ok, so I’ll give Nicky kudos for beating me to the punch on this topic. But, I’m also going to provide a better way to accomplish this task

So let’s consider this scenario. You have an SBS 2003 box, and at some point in time you completed a side-by-side installation of Windows SharePoint Services 3.0, and you have been using your WSS 3 site instead of the default WSS 2 companyweb site on SBS 2003. Now you have this shiny new SBS 2008 box that is running WSS 3.0 already.

Nick’s article gives you an option to move your WSS 3.0 site from your SBS 2003 box to the companyweb site on your SBS 2008 box. But there’s one downfall – by using the backup & restore functionality in SharePoint’s stsadm utility, you’re effectively deleting the stock SBS 2008 companyweb site, and putting your existing WSS 3.0 site in its place. Not that may not be a huge deal, but what if you want to use the SBS fax service and have faxes routed to your companyweb? Well the fax library doesn’t exist (unless you’ve manually created it exactly like the SBS team had it). Not to mention, your WSS 3.0 site that you restored most likely isn’t set up with the same security that the stock SBS 2008 companyweb used – meaning new users won’t automatically have access to the site unless you tweak the permissions.

Instead of yanking out the stock SBS 2008 companyweb and replacing it with your existing WSS 3.0 site, the better solution is to integrate your existing site into the SBS 2008 companyweb. And believe it or not – it is entirely possible (and even pretty simple) to do so

First and foremost – in order for this to succeed, you need to be running the same version of WSS 3.0 on both your SBS 2003 and SBS 2008. On both servers, open SharePoint 3.0 Central Administration, navigate to the Operations tab, then click on the Servers in Farm link. This will show your server along with its WSS version (e.g. 12.0.0.6303). Install any missing Service Packs / Updates so both servers are at the same version. Penny has a great post here on identifying what updates correspond to what SharePoint version.

On your SBS 2003 box, open a command prompt and navigate to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin and enter the following command:

stsadm –o export –url http://[sitename] –filename [output path] –overwrite –includeusersecurity –versions 4

Where [sitename] = the name of your existing WSS 3 site and [output path] is the path to the directory where you want to store the export (e.g. D:\WSSExport\sitename.dat ). If the path includes long file/folder names, enclose the entire path in double quotes (e.g. “D:\WSS Export\sitename.dat”

This command exports the contents of the specified site. The –overwrite flag tells stsadm to replace the output file if it already exists. The –includeusersecurity flag does just that – tells stsadm to include user security settings for all entities in the site. Finally, the –versions 4 flag tells stsadm to export all versions of list items and documents.

By default, stsadm will create a new file when the output file reaches 25MB in size. So if your resulting export is 90 MB, you will have four files – the first three being 25 MB each, and the last being 15 MB.

Once the export completes, copy your export file(s) to your SBS 2008 box. Then, on your SBS 2008 server, open a command prompt with administrator privileges. Navigate to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin and enter the following command:

stsadm –o import –url http://companyweb –filename [input path] –includeusersecurity

Obviously, [input path] is the path to the location of the export files you copied to your SBS 2008 box. Again, if there is a long file / folder name, enclose the entire path in double quotes. If the output produced more than one file, you should specify the first file in this command e.g. “D:\WSS Import\sitename.dat”

When the command completes, you can navigate to http://companyweb. Your first impression will be that you are looking at your original WSS 3.0 site – because the companyweb will be using the theme, Quick Launch & Top Link bars from the imported site. However, the two sites have actually been merged in to one.

Every list, library, and sub-site from your previous site that did not already exist in the SBS 2008 companyweb was created with the previous security settings and all content (including versions) restored.
Every list, library, and sub-site that exists in both sites have been merged, so that content from the export has been added to the corresponding entity in the SBS 2008 companyweb. (For example - if your original WSS 3.0 site included an Announcements list, you will see that both your previous announcements and the SBS 2008 companyweb announcements exist in the same announcements list).
SBS 2008 companyweb entities are still present – including the Fax Center document library and the Archived E-Mails sub-site.
Security for the two sites have been merged. The default groups used by SBS 2008 are still present and granted access. Additionally, user permissions from your original site have been merged in to the site as well.

At this point, you just have some basic tweaking to do – including adding the Fax Center library and/or Archived E-Mails sub-site to the Quick Launch, etc.

For simplified administration moving forward, I recommend reviewing permissions throughout the site and replacing permissions on the old site with the groups used by SBS 2008. The fewer groups that are used, and the fewer explicit permissions granted to specific users, the easier your SharePoint security administration will be moving forward. Note that you can add Active Directory Security Groups as members to SharePoint groups. This way you can use SharePoint groups to control access to libraries, lists, & sub-sites in SharePoint. Additionally, you can then create new User Roles in your SBS 2008 Console that include membership to necessary AD Security Groups. This way, when you create a new user via the SBS 2008 console, you can select the correct User Role, and the resulting new user will automatically have access to the right areas in your companyweb.

Windows SharePoint Services 3.0 and the IIS default web site

cgross — Fri, 20 Mar 2009 00:20:00 GMT

So I was visiting with a friend last night, and he indicated that he was having a bit of a problem with his WSS 3.0 installation. Short story is that he has a dedicated Win2k8 box acting as a web server on his domain for internal sites. They have several web-based LOB apps that run on that box, all as virtual directories under the default web site. Even though they are running SBS 2003 with its WSS 2.0 companyweb, they wanted to install WSS 3 to take advantage of the new wiki site template. So, they installed WSS 3 on the web server, which immediately broke their LOB apps.

So what happened?

When you first install WSS 3.0 and run the SharePoint Configuration Wizard, SharePoint creates a new web application (SharePoint – 80) and creates a new web site in IIS that takes over the default site. Dana recognized this, so within IIS he edited the bindings for the SharePoint site to use port 81, allowing him to re-enable the original default website in IIS and get his LOB apps back. The problem? Not only was it a pain having to enter :81 after the servername to access the site, but clicking links on the SharePoint site continued to want to use port 80, resulting in constant 404 errors.

So how did we fix it?

If you’re new to SharePoint, it is worth taking a little time to explain some of the architecture and terminology around SharePoint 3.0 to help put the answer in to context. First, it is important to understand the distinction between a SharePoint web application, and an IIS web site. SharePoint (whether WSS or MOSS) can have multiple web applications. These are created via SharePoint Central Administration. You can think of a SharePoint Web Application as your top-level SharePoint site – but it is distinctly different from a website in IIS. An IIS site that is mapped to a SharePoint web application can be thought of as a gateway to access the SharePoint web application. You can delete the site from IIS without affecting any of the content in the SharePoint application. (Obviously you won’t be able to access the SharePoint web application without an IIS site, but none of the SharePoint web application content or configuration is stored in the IIS site).

There are several benefits to this approach – including the ability to have multiple IIS sites mapped to a single web application, with each site being bound by a different SharePoint security zone. The distinction between the web application and the IIS site in Dana’s situation is that the original IIS site that was bound to port 80 with no host header was separate from the actual SharePoint web application, and even though that was the initial IIS site created to access the SharePoint web application, it isn’t necessary to use that IIS site.

The simplest solution for Dana was to create a new IIS site that used a host header to access his SharePoint web application. This is actually very simple and straight-forward to do from within SharePoint Central Administration:

Open SharePoint Central Administration (Start | Administrative Tools | SharePoint 3.0 Central Administration) on your SharePoint server.
Click on the Application Management tab
Click on the link to Create or Extend an Existing Web Application
Click the link to Extend an Existing Web Application (we are extending an existing web application to another IIS site)
Select the web application you want to extend. (The default SharePoint web application on a stand-alone WSS installation is SharePoint – 80. On SBS 2008, the companyweb application is remote.yourdomain.com:987 )
Select the option to create a new website and enter a description that is meaningful to you (this will display in IIS)
Change the port to 80
Enter a value for the host header (in Dana’s case, we used wiki - obviously, you will need to create the necessary DNS records so your host header name can be resolved via your internal DNS. I personally prefer to create a CNAME (alias) that resolves to the host (server) that is running SharePoint. Alternately, you could also create a new A record).
In a typical small business deployment, you will accept the default security configuration options
Select the appropriate zone and click OK.

This will create a new site in IIS that is mapped to the web application you selected. After we had created the new site for Dana and created the necessary CNAME record for wiki in his DNS, we were able to browse to http://wiki on his internal systems and access the SharePoint application successfully, and navigate without 404 errors.

Additionally, we were able to delete the original IIS site that Dana had changed the bindings to port 81. Since Dana & co were now accessing the web application via the new site (http://wiki) we didn’t need the original site on port 81 any more. We also did this within SharePoint central administration:

Go to the Application Management tab
Click the link to Remove SharePoint from IIS Web Site
Select the web application
Select the site
Optionally select to delete the site from IIS (which we did select in Dana’s case)

So why was Dana getting the 404 errors after he changed the bindings to a new port number in IIS? If you go back to the page where we extended the web application, take note of the description under the Load Balanced URL section:

The description reads: “The load balanced URL is the domain name for all sites users will access in this SharePoint Web application. This URL domain will be used in all links shown on pages within the web application. By default, it is set to the current servername and port.”

When the SharePoint Configuration Wizard created the initial web site in IIS, the SharePoint load balanced URL for that site was http://servername:80 - which will resolve to the default website on that server. When Dana changed the port to 81 and re-enabled the original default website, links in the SharePoint web application (when accessed from the original IIS site) all used the Load Balanced URL, which resolved to the re-enabled default website on port 80 – thus resulting in the 404 errors.

The moral of the story here? Well there are a couple:

You can have as many IIS sites linked to a single SharePoint web application as you want.
When administering SharePoint, do as much as you can in SharePoint Central Administration. Chances are you won’t get the results you want if you try to make changes (such as site bindings) via IIS.

One of my personal rules when it comes to IIS is to leave the default website alone. Personally, I always create new websites in IIS and use host headers to access those sites – so everything is accessible on port 80 (assuming http) and users don’t have to remember weird port numbers, etc. Additionally, using host headers gives you the freedom to move websites to different web servers without affecting the end-user experience. Just update your DNS record for the host header value to point to the new server and voila! – users are accessing the same site via the same URL and have no idea it has been moved to a different physical box. And this is true of all web applications I use – DotNetNuke, Community Server, etc.

The only exception to my rule of putting each web application in their own IIS web site is when we need multiple apps all on the same server accessible via SSL. Since SSL traffic is encrypted, IIS is unable to inspect the host headers, meaning it can only direct SSL requests to the correct site based on the IP / port combination. So, to have multiple web apps on a single box accessible via SSL, we either need to have multiple sites all on one IP listening on different ports (443, 444, etc.), or multiple IPs on the box so each site can listen on 443 on a separate IP, OR configure the different web applications as virtual directories under one IIS site that is listening on 443 for the one / all IP addresses. Depending on the number of applications you need accessible via SSL, it can makes more sense to configure those apps as virtual directories under a single site, so you reduce your administrative overhead by not having to administer multiple IP addresses / ports / SSL certificates. But even then, I create a new site in IIS to put everything under instead of using the default site. Yeah, I know – I’m weird like that

Of course – there is always more than one way to skin a cat, so there is a completely different method we could have taken to fix Dana’s issue as well.

Let’s say there was a business need for Dana’s web applications (that were all virtual directories under the default site) to be accessible as virtual directories under his SharePoint site. This approach was actually recommended to Dana by other individuals telling him to add an Application Exclusion to the SharePoint site. Dana couldn’t find out how to do this – but there is good reason why: Application Exclusions don’t exist in SharePoint 3.0.

Here’s the deal: SharePoint 2.0 and 3.0 have considerable distinctions in their architecture. For example, when you extended SharePoint 2.0 to a website in IIS, SharePoint assumed that the entire IIS site would be devoted to the SharePoint application. As a result, if you wanted to have non-SharePoint virtual directories under the IIS site, you had to tell SharePoint 2.0 to exclude those virtual directories from its management, allowing the web applications in those virtual directories to work as intended.

SharePoint 3.0 uses a different approach. Instead of assuming the entire IIS site is devoted to the SharePoint web application, you have to explicitly tell SharePoint what paths in the IIS site are managed by SharePoint. When we create a new SharePoint Web Application, SharePoint assumes that it will manage the root path as well as everything below the /sites/ path. (Hint: when you create a new web application and are on the Create Site Collection page, this is why you have the to options for the URL: http://hostheader/ or http://hostheader/sites/ )

What this means is that SharePoint 3.0 plays very nicely with other web applications in the same IIS site. So in Dana’s case, when he first installed SharePoint 3.0 and it created a new IIS site that replaced his original default website, he could have simply recreated the virtual directories for each of his web based LOB apps under the IIS site SharePoint created as long as none of them used the sites name, since that was defined as a Managed Path for the SharePoint web application. And even then, if he wanted to use the sites path for a non-SharePoint application instead, he could have removed the sites path from SharePoint management.

You can administer SharePoint’s managed paths from SharePoint Central Administration. Simply navigate to the Application Management tab and click the link for Define Managed Paths. When you add a managed path, you specify what type of inclusion it will be. There are two types of inclusions – an explicit inclusion and a wildcard inclusion. An explicit inclusion means that SharePoint will manage just that path, where as a wildcard inclusion tells SharePoint that every path under the wildcard inclusion path should be managed. This is particularly useful if you are enabling self-site creation for users, so they could effectively create their own site collections (top-level SharePoint site) under a common directory (e.g /sites/).

Managing Sharepoint in SBS 2008

cgross — Tue, 17 Mar 2009 16:26:49 GMT

Join me and Amy Babinchak this Thursday (3/19) @ noon Eastern time as we discuss managing Windows SharePoint Services 3.0 in Small Business Server 2008. We will be talking about the what has changed with SharePoint from SBS 2003 to SBS 2008, most notably the move to WSS 3.0 and the new features & functionality available. We will also be talking about emailing SharePoint lists & libraries directly, as well as backup and disaster recovery considerations

When: Thursday, Mar 19, 2009 12:00 PM (EST)
Scheduled to Occur: Once
Duration: 1:30

Third Tier has invited you to attend an online meeting using
Microsoft Office Live Meeting.

https://www.livemeeting.com/cc/mvp/join?id=9THDZK&role=attend&pw=RpJ%285j%3A%2F6

Meeting time: Mar 19, 2009 12:00 PM (EST)

Add to my Outlook Calendar:
https://www.livemeeting.com/cc/mvp/meetingICS?id=9THDZK&role=attend&pw=RpJ%285j%3A%2F6&i=i.ics

AUDIO INFORMATION
-Computer Audio(Recommended)
To use computer audio, you need speakers and microphone, or a
headset.

FIRST-TIME USERS
To save time before the meeting, check your system to make sure it is
ready to use Microsoft Office Live Meeting.
http://go.microsoft.com/fwlink/?LinkId=90703

TROUBLESHOOTING
Unable to join the meeting? Follow these steps:
1. Copy this address and paste it into your web browser:
https://www.livemeeting.com/cc/mvp/join
2. Copy and paste the required information:
        Meeting ID: 9THDZK
        Entry Code: RpJ(5j:/6
        Location: https://www.livemeeting.com/cc/mvp
If you still cannot enter the meeting, contact support:
http://r.office.microsoft.com/r/rlidLiveMeeting?p1=12&p2=en_US&p3=LMInfo&p4=support

NOTICE
Microsoft Office Live Meeting can be used to record meetings.
By participating in this meeting, you agree that your communications
may be monitored or recorded at any time during the meeting.

Specifying a Custom Port for SmartHost Communications in SBS 2008

cgross — Mon, 09 Mar 2009 18:57:02 GMT

Just this morning I helped a partner with this very scenario. Unlike previous versions of Exchange, Exchange 2007 does not provide an interface within its management GUI to specify a custom port when using a SmartHost for outbound mail delivery. As a result, we need to set this via the Exchange Management Shell.

Once you open the Exchange Management Shell, one simple command will allow you to specify the custom port to use:

set-sendconnector –identity ‘[Send Connector Identity]’ –port [Port Number]

In SBS 2008, the default Send Connector that gets created is named “Windows SBS Internet Send [SERVER]” where [SERVER] is the netbios name of your SBS server. So for example, if your SBS box was named SERVER01 and you needed to use port 2525 to send email to your smart host, you would enter:

set-sendconnector –identity ‘Windows SBS Internet Send SERVER01’ –port 2525

If necessary, you can find the identity (name) of your Send Connector(s) from the Exchange Management GUI, or from the Exchange Management Shell.

In the GUI, expand Organization Information, select Hub Transport, then click on the Send Connectors tab.

In the Exchange Management Shell, run the get-sendconnector cmdlet to get a list of send connectors.

Which RMM?

cgross — Tue, 03 Mar 2009 15:38:31 GMT

Ah, the great debate in the SMB Managed Services realm: what is the better Remote Monitoring & Management (RMM) solution? I don’t know how many times I’ve been asked this question by SMB providers, so I decided it would be beneficial for a no-holds-barred comparison of the products I know. Obviously, it will not be a comprehensive comparison of every available solution, since I am only going to compare the products I know and have worked with first hand: IT Control Suite, Level Platforms’ Managed Workplace, and Kaseya.

This will be a multi-part series, with each entry focusing on one aspect of RMM functionality (monitoring, patching, scripting, remote access, etc.) and providing a comparison of how each of the three solutions approaches the functionality and how well they deliver, noting gotchas to be aware of.

For those of you who aren’t familiar with me, I have been involved with providing managed services in the SMB space since mid-2003. In mid-2004 we were one of Level Platforms’ earliest customers. In early 2006 we added Kaseya and started running it side-by-side with Managed Workplace. Finally, in mid 2008 we began working with IT Control Suite as well. I spent two years as CTO of MSPSN, and during that time MSPSN offered vendor-agnostic NOC services, allowing SMB MSPs to use whatever RMM product they wanted. Part of my duties included administering multiple RMM installations to keep them in sync with MSPSN’s standardized monitoring and ticketing configuration, but also training NOC staff on these products as well. As a result, I have in-depth first-hand experience with these products. I know each one’s killer features, what they do well, what they could do better, and in some cases what they flat-out don’t do.

Before we dive in with the series, it is important to note that if you are providing Managed Services, and do not have any RMM solution in place, any one of these is a viable choice that will enhance your offering(s) and help streamline your service delivery. There is no wrong answer – just a potentially better answer depending on your needs and priorities in an RMM solution. Just be aware that no RMM is truly “set it and forget it” – they all require on-going administrative effort to keep doing their job well, although some do require less admin overhead than others.

Large Files in SBS 2008’s Companyweb

cgross — Thu, 26 Feb 2009 03:29:00 GMT

If you are making use of document libraries in your companyweb on SBS 2008, you may have noticed that you aren’t able to upload large files (> ~28MB) to a document library. When you attempt, you receive a 404 error in your browser. Additionally, you have tried setting the upload size in SharePoint Central Administration, but you are still encountering the problem.

This behavior is due to certain changes within IIS7. To increase the upload file size limit for your SBS 2008 companyweb, you must edit the web.config file for the companyweb application in addition to increasing the limit in SharePoint Central Administration.

First – set the new limit in SharePoint Central Administration (if you haven’t already):

Log in to your SBS and navigate to Start | Administrative Tools | SharePoint 3.0 Central Administration
At the User Access Control prompt, click Continue
In SharePoint 3.0 Central Administration, navigate to the Application Management tab and click on Web Application General Settings.
On the Web Application General Settings page, verify that the selected web application is https://remote.domain.com:987.
1. If this application is not selected, click on the web application and select Change web application.
2. In the Select Web Application window that opens, click to select the SBS SharePoint application.
In the Maximum Upload Size field, enter the maximum upload size you want to allow.
Scroll to the bottom of the page and click OK to save the changes.

After setting the increased limit in SharePoint 3.0 Central Administration, you must set the increased value in the companyweb web.config file:

Open My Computer and navigate to C:\Program Files\Windows Small Business Server\bin\webapp\InternalWebSite
Right-click on the web.config file and select Properties.
Go to the Security tab and verify the administrative user you are logged in as has modify permissions on this file. (By default, the administrator account you create during setup will only have read access).
If necessary, click the Edit button to give your administrative user Modify permissions.
Click OK to close the file properties.
Open the web.config file in notepad.
Scroll to the bottom of the file. Directly above the </Configuration> line, enter the following:

</System.Workflow.ComponentModel.WorkflowCompiler>
 <system.webServer><security><requestFiltering><requestLimits maxAllowedContentLength="52428800" /></requestFiltering></security></system.webServer>

The maxAllowedContentLength= value listed is in bytes. The value dispayed (52428800) corresponds to 50 MB. I recommend making this value slightly larger than the max upload size you specified in SharePoint 3.0 Central Administration. If this value is equal to or less than the value in SharePoint 3.0 Central Administration, users may not receive the friendly error page indicating they exceeded the file size limit.
Save the changes to the web.config file.
Open IIS 7 Administration (Start | Administrative Tools | Internet Information Services (IIS) Manager ).
Expand <servername>, then expand Sites.
In the list of sites in the content pane, click to highlight the SBS SharePoint site.
In the Manage Web Site section of the right-hand pane, click Restart to restart the web site.

Your users should now be able to upload large files to your companyweb document libraries. However, depending on how large of files users are actually uploading, their uploads may still fail – not due to a size restriction, but rather an IIS timeout issue. To adjust the timeout values for your site, take a look at this post over on Don’s blog.

Installing Group Policy Preferences Client Side Extensions

cgross — Wed, 17 Dec 2008 05:57:04 GMT

In my previous post, I ran through a quick and dirty overview of Group Policy Preferences in Windows 2008. One little tidbit of information to note is that in order to take advantage of Group Policy Preferences in your Windows 2008 domain, you need to have the Group Policy Preferences Client Side Extensions installed on your PCs and Servers. The Client Side Extensions are installed on Windows 2008 systems by default, but they must be deployed to your XP, Vista, and 2003 devices in order to take advantage of Group Policy Preferences.

Like virtually everything in IT - there is more than one way to skin a cat. The GPP Client Side Extensions are available as an update for Windows (KB 943729). So if you have a method for centralized deployment of updates, you can push this update out to all of your machines. If you're using WSUS - 943729 is classified as a Feature Pack - so you will need to be synchronizing all Feature Pack updates in order to deploy this via WSUS.

If you don't have an automated method for deploying updates, or if you're just a bit sick & twisted like I am, we can configure our SBS 2008 domain so that all machines get the update installed automatically via a GPO startup script. I personally like this approach for a few reasons. First - once it's set up, we don't have to do anything special. If we add a new machine to the domain, it will get the Client Side Extensions installed automatically at startup. And considering the few reboots that happen when joining a PC to the domain via http://connect - the CSE will almost always be installed before the user logs in for the first time. This is beneficial to relying on WSUS - because even if we have the update approved for installation, when the PC is first joined to the domain it has to check in with WSUS, and depending on our patching schedule, it could take several days until the CSE actually gets installed. If we're relying on Group Policy Preferences to handle our drive mappings, printer installations, etc. - it's obviously preferable to have the CSE installed as soon as possible.

So, I've put together a little vbscript to handle the installation of the Group Policy Preferences Client Side Extensions. This script can be used in a number of fashions - from running it manually on a device, to using your favorite Remote Monitoring & Management product (Level Platforms, Kaseya, etc.) to deploy it, or by using it as a startup script in a domain Group Policy Object.

A few details regarding the script:

The script assumes that the CSE installers are present on the LAN. Therefore you will want to make sure each of the six variations of the CSE installer (both x86 & x64 for Vista, XP & 2003) are downloaded to a share on your network.
You will need to edit the paths to the installers in the script. The defined paths can be found on lines 47 - 52. Note that these paths must be UNC paths to work.
If you are going to use the script as a domain startup script, remember that startup scripts execute under the computer account's security context - so you will need to make sure that your Domain Computers security group has read access to the share where the script and the CSE installers reside.

I've tested the script on a number of systems, and it has worked flawlessly on each. However, as usual I make no warranties of any kind, and if you choose to use this script in a production environment, you do so at your own risk