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:

1. 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.
2. 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.
3. 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 . . .
4. In my case, I update my domain login script to call my DisableProxy.vbs script at this point.
5. 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.
6. 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  [:)]
7. Follow Kevin’s steps 3-9 to remove ISA from the server.
8. 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 . . .
9. 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.

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.

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:

1. 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\
2. Right-click on the ExtensionList key and select New –> String Value
3. Enter  38  for the new string value and hit Enter
4. 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.
5. 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.

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

1. Open a command prompt (as Administrator) and run an  iisreset
2. After the iisreset completes, change your working directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin
3. Stop the SharePoint search indexing process by running this command:  stsadm –o spsearch –action fullcrawlstop
4. 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!

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:

1. Disabling the loopback check all together.
2. Tweaking the Alternate Access Mappings in SharePoint (unless you need to for other legitimate reasons – not the 2436 error)
3. 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. 

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

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.

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.

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.

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):

1. Log in to your SBS and navigate to Start | Administrative Tools | SharePoint 3.0 Central Administration
2. At the User Access Control prompt, click Continue
3. In SharePoint 3.0 Central Administration, navigate to the Application Management tab and click on Web Application General Settings.
4. 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.
5. In the Maximum Upload Size field, enter the maximum upload size you want to allow.
6. 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:

1. Open My Computer and navigate to C:\Program Files\Windows Small Business Server\bin\webapp\InternalWebSite
2. Right-click on the web.config file and select Properties.
3. 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). 
4. If necessary, click the Edit button to give your administrative user Modify permissions.
5. Click OK to close the file properties.
6. Open the web.config file in notepad.
7. 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>

8. 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.
9. Save the changes to the web.config file.
10. Open IIS 7 Administration (Start | Administrative Tools | Internet Information Services (IIS) Manager ).
11. Expand <servername>, then expand Sites.
12. In the list of sites in the content pane, click to highlight the SBS SharePoint site.
13. 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.

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:

1. 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.
2. 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.
3. 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