Grant Thompson's Blog

We've been working with SharePoint for years – implementing, developing, hosting as well as using it for our own internal systems and our public website – www.mgtechgroup.com. Recently I was working with one of our resellers getting their internal staff up to speed on Windows SharePoint Services 3.0. As I did a really basic demo of the features, one of our office staff overheard and I was amazed to learn had no idea how to use these features. Sometimes we forget to share the simple things…

We use SharePoint for all kinds of things but I only occasionally go to our SharePoint site MGWeb. The reason is that I access it primarily through Outlook. I always have Outlook open for e-mail, my calendar and tasks and we also use Dynamics CRM which is integrated as well. This allows me to do much of my daily communications and information gathering from one application, very efficient and easy to use.

These screen shots are from Outlook 2010 but you can do this on Outlook 2007 as well. If you are using a previous version you can do some things with Outlook 2003 but before that you're out of luck – time to upgrade. We host Office and can also help with discounted licenses (shameless plug).

Connecting a Document Library to Outlook

This has got to be one of my favorites. This will allow you to have access to documents stored on SharePoint from within Outlook. This includes attaching them to an e-mail, editing, search, and working with them offline.

To connect a document library to SharePoint:

1. Log on to your SharePoint site
2. Navigate to the document library
3. Click the Actions menu and choose Connect to Outlook
   
4. Depending on the version of Windows, Office and Internet Explorer you are running you may see the following (or something similar)
   
   
   Obviously click Allow since you know you are linking to a safe site.
   
   
   
   Click Yes.
5. Now you will see the document library in Outlook
   
6. If there are folders you can expand them, you can select documents and see them in the preview pane of Outlook. You can double-click them to open them (remember how to work with SharePoint documents to ensure your changes are saved back to SharePoint – this is even easier in Office 2010).

Attaching a document to an e-mail from SharePoint

Now that you have your document library connected let's look at what you can do with it. One thing I use all the time is attaching a document to an e-mail. I must point out that if you are sending something to someone who has access to the SharePoint site, just send them a link! One of the benefits of SharePoint is to stop sending documents by e-mail to ensure everyone is working with the same document and to prevent your mailbox from filling up with copies of the same document. However, I work a lot with prospects and am often sending them documents we have in SharePoint.

Option 1: Forward

1. From Outlook, right-click the document in the SharePoint Lists section
   
2. Select Forward (you can also click forward on the tool or ribbon bar)
3. Enter your e-mail recipient and other info
4. Click Send

Option 2: Drag and drop

In the option above, you get a nice e-mail with your signature, the filename as a subject and the document attached. However, as often happens I start writing an e-mail and then decide to attach a document. To do this, follow these steps:

1. Switch from your e-mail back to Outlook
2. Open the SharePoint list on the left side (if you don't see SharePoint Lists make sure you are in Inbox or Folder view and that you have one connected)
3. Click and drag the document you want to attach to your e-mail. HINT: if your e-mail window is no longer visible, drag the file to the Task Bar and hover over the e-mail "task". If you are running Windows 7 it looks like this:
   
   The task bar with two Outlook tasks (one is my Inbox and the other is my new e-mail) as I hover over the Outlook icon I see this:
   
   
   
4. Now drag the file to the message task (in Vista and XP the window will appear when you hover over the task). Then I can drop the file on the body of the e-mail and it will attach

Option 3: Send the link!!!

I mentioned above sending a link to users who have access to SharePoint. It's so easy to do and you still don't have to leave Outlook.

1. Open the SharePoint list on the left side of Outlook
2. Right-click the document you want to send a link to
   
3. Click Copy Shortcut
4. Paste this into your e-mail

I'm out of time for this post, enjoy!

We at MG Technology Group are proud to announce the availability of our next-generation disaster recovery solution powered by Doyenz.

We've been active in the small and mid-sized business (SMB) space for many years. Disaster recovery was and still is a top concern for most businesses. There have been some significant improvements over the years – especially recently with the wide-spread availability of virtualization.

In general the key components of a disaster recovery plan include:

• Frequent backups
• On-site and off-site storage of backups
• Testing of the backups to ensure they are usable
• Duration of backups and restore must minimize disruption to the business

Many solutions are available that meet these requirements. The catch, however, is how well they meet them. For example, using tape as a backup media is slower than using a hard disk.

Our new disaster recovery solution works like this:

• Local backups are taken – these backups are hardware agnostic (meaning they can be restored to any machine that meets a basic set of requirements) – typically a full backup and then incremental every 15 minutes.
• The backups are done to a local USB drive.
• The backups are also synced to a data center located in the US (critical for some compliance issues)
• The backups in the data center can be accessed via a web console – including starting up the backup machine in a "sandbox" (an environment not connected to anything outside of itself)
• In the event of a failure the local backup can be "restored" in minutes using any available hardware that meets the minimum requirements (in many cases a workstation can be used).
• In the event of a catastrophic failure we can have the server(s) up and running in our data center in minutes.

The first few bullet points are nothing new; there are a lot of companies offering these solutions. The features that make our solution different are that you can easily test your off-site backup to ensure it is fully functional. By seeing your server boot and having the ability to check files, databases, etc. you have 100% confidence it will be usable when it is needed. And this test takes very little time.

There are some added benefits of this "sandbox" environment as well that I will discuss in a future post – just imagine easily testing a Service Pack or other major change BEFORE doing it on a production server.

The other differentiator is the ability to "Failover in the Cloud". This means that in minutes MG Technology Group can turn on the last backup (or any other point in time backup still available) and make it available for production in our data center. The transition process is easy, backups continue to happen and restoring back to a local server after the disaster is easy.

It is true that some application will perform much slower over a WAN and a few will not function at all in a disaster having access to most of your server functions versus none can make or break a business.

Around 50% businesses fail during a disaster – largely due to the inability to continue doing business. A major contributor to this is a lack of IT systems.

We also have "desktops" available via Terminal Services that can be brought on-line quickly should a business need applications that will not tolerate WAN speeds.

Imagine the possibilities – your customers (if you are an IT service provider) or your business can continue to function during a disaster.

We have a great partner program for this and other solutions. You can contact us at:

MG Technology Group – The Solution to Business Evolution™
www.MGTechGroup.com | 1-866-350-9310

Some of the information in this article was gathered from:

• http://en.wikipedia.org/wiki/Disaster_recovery
• http://www.doyenz.com
• http://www.disaster-recovery-guide.com/
• http://www.disasterrecoveryforum.com/

When installing Team Foundation Server 2008 using an existing MOSS deployment we ran into the following error:

TFS2200401: The specified Windows SharePoint Services site URL (http://server) is not the default site collection site: (). The default site collection site might have been renamed or removed. Make sure that the site exists and verify the correct URL, and then attempt installation. If the problem persists, you can choose to install and configure Windows SharePoint Services as part of the Team Foundation Server installation process.

I looked at the install log file: dd_install_vstf_at_90.txt and found:

wsschecker.exe : Another site already exists at http://server. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.

I tried a few different things with no luck.

Resolution:

In the end I created a new site collection (interesting the existing site collection was at http://server and not http://server/sites/x). When I created the new site collection I was given the default http://server/sites/ option and filled in a new URL. TFS installed fine from there.

Now we have to integrate the TFS site collection into the client's existing site collection or migrate their old site collection to the new one. J

I've seen a lot written about this particular issue. We just ran across this yesterday and here is how I solved it.

Symptoms:

Logging in to the MOSS/WSS Central Administration web site works fine from the local machine (MOSS central admin server) but when logging in from remote machines an NTLM prompt is presented and domain admin, domain farm admin, etc. accounts are "not authorized". The typical behavior of the NTLM prompt coming up three times before the error page (401.1) is displayed.

However, I found that if I logged in as the local machine administrator (of the MOSS server) it worked fine. For example DOMAIN\Administrator fails but SERVERNAME\Administrator works.

Troubleshooting:

It was clear to me that this was an authentication problem and had nothing to do with MOSS. To test my theory I created a simple web site in IIS and turned off anonymous access. Then I tried connecting to that site remotely and it worked. I had actually expected it to fail. Next I set my test web site to use the same application pool as central admin. This time my test site behaved the same as central admin. The common thread here is Kerberos authentication was not working when run using the central admin app pool user account.

I ran SetSPN (you can download this from www.Microsoft.com/downloads if you don't have it) –L domain\moss central admin account (in this case domain\MOSS_CA). Sure enough there were no entries.

Resolution:

Run SetSPN –A http/server.domain.local domain\MOSS_CA (remember that you need to substitute your server, domain and account).

Next open Active Directory Users and Computers (with access to your domain's AD) and find the domain\MOSS_CA account (whatever your central admin app pool is running under) and open properties. Click on the Delegation tab and choose "Trust this user/computer for delegation to any service (Kerberos)".

At this point I had to reset the password on the service(s) using the account and update the account's permissions in SQL Server. Then I rebooted and everything was working properly.

If you need additional information (i.e. more details about where to find your Central Admin app pool account, etc.) leave a comment and I'll do my best to get back to you.

Setting up a Microsoft Dynamics CRM 3.0 system where the laptop clients are running Windows Vista and Microsoft Office Outlook 2007 I attempted to install the laptop client from the CRM_VC3_CLIENT.iso which is for Vista and Outlook 2007 (get it here). NOTE: this is for "on premise" for service providers there is a different ISO.

The error I got (see below) is:

The type initialize for
"Microsoft.Crm.Setup.Common.CommonResource" threw an
exception.
File or assembly name Microsoft.Crm, or one of its dependencies, was
not found.

The first problem was easily fixed:

The System Requirements screen said that the Indexing Service was not installed – this is used for backward compatibility in Vista. To resolve I opened Appwiz.cpl and installed the Indexing Service.

No big deal. To ensure everything was clean I did a reboot. Then I ran setup again and got this:

I did a Google search and came up empty (except for others asking how to fix it). So here's the fix:

1. Disable and stop the Indexing Service
   1. Open services.msc
   2. Open the Indexing Service properties page
   3. Set it to disabled and stop it
   4. Click Apply
      
      
2. Run the CRM client setup again. This time you will get back to the System Requirements screen and see the following:
   
   
3. Leave setup open and go back to services and set Indexing Service to automatic and start it (note: you must click Apply after setting it to Automatic before you can start it).
   
   
4. Lastly, go back to the CRM setup System Requirements dialog and click Back and then Next and finish your install.

Hope this helps

This is a general error but here's where I ran across it.

On a network running SBS 2K3 R2 we were troubleshooting use of IPv6. We had it working on another server and one thing we did was compare installed updates. On the functioning server an update named "Windows Small Business Server 2003 R2" was listed. So we reinstalled the R2 technologies on the non-working server.

Then came the problems, first RPC via HTTP stopped working. After finding that RPC was disabled and enabling it (did not fix the issue) the Active Sync issue appeared.

The solutions was to enable Integrated Windows authentication on the exchange-oma virtual directory.

1. Open IIS
2. expand to Web Sites\Default Web Site
3. right-click exchange-oma and choose properties
4. click the Directory Security tab
5. click the Edit button in Authentication and access control
6. check the Integrated Windows authentication box
7. click OK twice

On Windows XP SP2 I have run across this error a few times. Typically it is an unhandled exception in C:\Windows\msiexec.exe when trying to open Outlook for the first time. Detect and Repair Outlook (or other Microsoft Office applications returns the same error. No Office Updates will install.

I never determined the exact cause of the error but the following steps solved it.

1. Download all versions of the .NET framework from www.microsoft.com/downloads (at the time this post was written they were 1.0, 1.1, 2.0 and 3.0)
2. Install 1.0 then 1.1 then 2.0 then 3.0 - each time choosing reinstall or repair.
3. Reboot the machine
4. Repair Outlook or Office
5. Install Windows Updates and Office Updates (optional but recommended)
6. Test

I believe this is corruption in the .NET framework somewhere along the way that breaks the C++Runtime Library.

Here are the downloads:

1.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=d7158dee-a83f-4e21-b05a-009d06457787&DisplayLang=en

1.1 http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&DisplayLang=en

2.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en

3.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043&DisplayLang=en

1. Create (or have the user create) and invitation file and send it to you or save it somewhere you can get it (i.e. a network share). Ensure the invitation is created using the Administrator account (or another account with privileges you need).
   1. Log on to the machine you want to control as Administrator
   2. Click Start/Help and Support
   3. Click Invite a friend to connect to your computer with Remote Assistance
      
   4. Click Invite someone to help you
      
   5. Choose your delivery method - depending on what is functioning on the machine Save invitation as a file (Advanced) is usually the best
      
   6. Accept the default name and expiration or change them as needed. NOTE: If the session will require a reboot you may want to extend the invitation expiration so you can use the same invitation to connect over a period of more than 1 hour.
      
   7. Click Continue
   8. Enter a password - using a password is recommended but not required. If you choose not to use a password uncheck the Require the recipient to use a password box
      
   9. Click Save Invitation (or Send Invitation) - note if you use IM this is different
2. Reboot the machine in Safe Mode with Network Support. You can do this with MSConfig:
   1. Click Start/Run, type msconfig and click OK
   2. Click the BOOT.INI tab
   3. Select the /SAFEBOOT option and the NETWORK radio button
      
   4. Click OK and reboot the machine
   5. Log in as the user that created the invitation
3. Open the invitation file from the computer you are connecting FROM
4. On the remote computer accept the Remote Assistance session
   
5. Initiate control on the computer you are connecting FROM
6. On the remote computer accept the remote control request

To turn off safe mode if you used MSConfig:

1. Click Start/Run, type msconfig and click OK
2. On the General tab choose Normal Startup
   
3. Click OK and reboot the machine

NOTE: If the ESC key is pressed on either machine Remote Control will be lost and the machine you are connecting to will have to accept it again. The ESC key cannot be pressed in key combinations (i.e. CTRL+ESC will stop remote control). Likewise a reboot will require steps 3-6 be repeated.

When you setup an FTP server on a Windows Server 2003 system you may run into this issue if you are using RRAS and have configured the server as an Application Server (which causes the Application Layer Gateway service to start). There is a known issue with FTP and this configuration for downloading large files. However this can also affect an FTP server where "Allow anonymous connections" has been disabled.

To solve this you must configure the Application Layer Gateway (ALG) service to not make port mappings for your FTP server.

Here is the fix:

1. On the server open Regedit
2. Navigate to HKLM\Software\Microsoft\ALG\ISV
   
3. Change the value of {6E590D61-F6BC-4dad-AC21-7DC40D304059} to Disable NOTE: not Disabled.
   

An IISReset is not required.

The Microsoft KB related to the large file download issue is here: http://support.microsoft.com/kb/931130/en-us

Thanks to Mark for setting up blogs for our company.