Speakers are our own fabulous staff: Dave Shackelford, Cliff Galiher, Eriq Neale and Wayne Small

Our content has been selected by the guys to reflect the growing concern over compliance, business continuity, manageability and issues surrounding these that our customers are contacting us for help with. Case studies and examples will abound and they guys will show you how to configure the products they will be working with which including Exchange, Sharepoint, Terminal Services and Hyper-V. Expect the sessions to be intense with advanced material. Your brain will be exploding by the end of the day.

I’ll be posting more and more specifics about the content as the event gets closer. Let’s have a look at what Eriq is going to cover first:

Configuring and Using Remote Desktop Services Remote Apps – A Love Story

Many people have heard of Remote Desktop Services Remote Apps (formerly Terminal Server Remote Apps) but either haven’t had an opportunity to implement the solution or just are not sure how to. In this session, Eriq Neale will show how to configure RDS Remote Apps on a Remote Desktop Server and then go over several real-world deployment scenarios. We will also go over how to set up RDS Remote Apps to work with Remote Web Workplace on an SBS Server. Eriq will include case studies on when and why this technology is used.

Configuring RDS Remote Apps

Publishing an Application through RDS Remote Apps

Publishing an Application with multiple configuration options through RDS Remote Apps

Publishing an RDS Remote App through Remote Web Workplace

Please make your flights accordingly and plan to join us for a full day of intense training on October 21st.

Shout Out to Hewlett Packard, Symform and Storagecraft. Without awesome vendors that get the small business space and are willing to invest in partner education, this event would not be possible.

—
Connect with us now…
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN

This article outlines the steps in slipstreaming service packs for SharePoint for use with Windows Server 2008 R2. I’ll work on a series of articles on how to deploy a NLB solution for SharePoint as well as implement Kerberos delegation for a SharePoint farm

In the morning when I got up and checked my email I was shocked to see only 3 new emails instead of the usually 30+. I wiped the blur from my eyes and noticed that all three email were from my own internal network. I first checked the usual suspects. Is my Internet up? Did my IP address change? Is my MX record still there? Is my firewall working correctly? Yes, yes, yes and yes. Time to look at the event logs and the Exchange server. Exchange server says my stores are mounted and Outlook says so too.

The event log had a story to tell. Fortunately for me the event log on this server is very clean otherwise I could have easily overlooked the error message that led me to the solution because it only occurs one time.  It’s Event ID 15006 Source MSExchangeTransport.

The Microsoft Exchange Transport service is rejecting message submissions because the available disk space has dropped below the configured threshold.

Resource utilization of the following resources exceed the normal level:
Queue database logging disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\") = 97% [Medium] [Normal=95% Medium=97% High=99%]
Physical memory load = 92% [limit is 94% before message dehydration occurs.]

Back pressure caused the following components to be disabled:
Inbound mail submission from the Internet
Mail submission from the Pickup directory
Mail submission from the Replay directory

The following resources are in the normal state:
Queue database and disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que") = 96% [Normal] [Normal=95% Medium=97% High=99%]
Version buckets = 0 [Normal] [Normal=80 Medium=120 High=200]
Private bytes = 3% [Normal] [Normal=71% Medium=73% High=75%]

As you can see the message is pretty detailed and tell you exactly what the problem is, except be sure to read the whole thing. At the top is says that transport service has stopped and is rejecting message submissions because the available disk space has dropped below the configure threshold. While it’s true the disk space was an issue it wasn’t enough to create the stop. Physical memory load was the problem. And the solution was, as Eriq pointed out in a earlier blog post and screencast, to reduce the amount of memory that Sharepoint and Monitoring databases are allowed to use on the server.

Read Eriq’s blog post here: http://www.thirdtier.net/2009/08/setting-the-maximum-memory-usage-on-the-sharepoint-database/

And what his screencast demonstrating the procedure here: http://www.thirdtier.net/screencasts/limit-sharepoint-database-memory-usage/

Note that after applying the fix, I had to restart the Exchange Transport service to get my incoming to start flowing again.

—
So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN

This recording and all previous are available on the Store tab of our website. http://www.thirdtier.net/store

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

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:

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/). 

Originally posted at www.msmvps.com/blogs/cgross