Aimless Ramblings from a Blithering Lunatic . . .

Just another Microsoft MVPs site

Month: March 2009

WOW

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

*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. 


  1. On your SBS, open Active Directory Users & Computers (Start –> Administrative Tools –> Active Directory Users & Computers.
  2. 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)
  3. Right-click on the OU and select New –> User
  4. On the first page of the new user window, enter the following info:
    • First Name:   SPSearch
    • Last Name:  <leave blank>
    • Username:   spsearch
  5. Click Next.
  6. Enter a strong password for the new account. 
  7. Uncheck the option “User must change password at next login”
  8. Check the option “User cannot change password”
  9. Check the option “Password never expires”
  10. Click Next
  11. Click Finish.
  12. 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). 


  1. When SharePoint 3.0 Central Administration opens, go to the Operations tab.
  2. Click on the “Services on Server” link
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

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.  smile_regular

Migrating a WSS 3.0 Site to SBS 2008

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  smile_regular

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  smile_regular

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

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:


  1. Open SharePoint Central Administration  (Start | Administrative Tools | SharePoint 3.0 Central Administration) on your SharePoint server.
  2. Click on the Application Management tab
  3. Click on the link to Create or Extend an Existing Web Application
  4. Click the link to Extend an Existing Web Application  (we are extending an existing web application to another IIS site)
  5. 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  )
  6. Select the option to create a new website and enter a description that is meaningful to you  (this will display in IIS)
  7. Change the port to 80
  8. 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).
  9. In a typical small business deployment, you will accept the default security configuration options
  10. 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:


  1. Go to the Application Management tab
  2. Click the link to Remove SharePoint from IIS Web Site
  3. Select the web application
  4. Select the site
  5. 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:


image


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  smile_regular


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

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

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?

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.