SharePoint 2010 No Code Search Center Customization

My session was fun, I love it when the audience gets involved and really thinks about what I am presenting. Here is a link to my deck and the links from the last slide.

SharePoint 2010 No Code Search Center Customization

• Basic Search Center Editing
• http://bit.ly/pCHMaW
• XML Test Results Page
• http://bit.ly/pyIb0X
• iFilter Shop iFilterView.exe
• http://ifiltershop.com/downloads/IFilterView.zip

Every once in a while SharePoint Crawler will behave unexpectedly on web sites that you wish to crawl. You may get error messages that you can understand and help you troubleshoot the problem or you will get just one error that is not helpful at all. Either way, I have found that you can troubleshoot the crawl by using the following technique with Fiddler Web Debugging Proxy (http://www.fiddler2.com). Using Fiddler we are going to configure SharePoint Search to crawl through Fiddler as a Proxy so we can watch the traffic.

1. Download and install Fiddler on the server running the crawl.
2. Determine which account is running the crawl. Usually it will be the Default content access account listed in Search Administration:

   

   Though, if you have crawl rules set up for specific content sources you may have alternate credentials specified, so check your rules and be sure you are using the correct account for testing.

3. Hold down the [Ctrl][Shift] keys and right click Fiddler to choose “Run as different user”. Log in as the Crawl Account. (If this option is not available, you may have to log out and log back in as the crawl account. Either way you need to run Fiddler as the crawl account.)

   

4. Once Fiddler is running choose Tools | Fiddler Options… and click the Connections tab. Note the Fiddler listens on port: setting. 8888 is the default. Ensure that it does not duplicate a port already in use by SharePoint. Close the dialog after making any necessary adjustments to the port.
5. Open a browser and go to http://localhost:8888 (or whatever your port number is for Fiddler) and you should see something like the following indicating that you are set up correctly.

   

6. To configure SharePoint to use Fiddler return to Search Administration and choose the link for Proxy Server from the System Status section.

   

7. Configure SharePoint to use Fiddler by choosing Use the proxy server specified and adding the address and port.

   

8. Click OK to save your settings.
9. Start the crawl for the content source that you are having issues with by choosing Content Sources. Select the content source and choose Start Full Crawl.

   

10. Once the crawl starts you should begin to see activity in Fiddler. In the example below I am crawling a small HTML web site. The crawler always looks for a robots.txt file first. In my case I don’t have one, so Fiddler displays the 404 result. Following that I see one result for each request.

    

11. Crawling a SharePoint site yields similar results, though you will notice that the crawler uses the SiteData service to gather information about the site from SharePoint.

    

12. Once you are done testing be sure to reset the Proxy settings in the Search Application.

     

Armed with the results of the Fiddler trace you can see the conversation that SharePoint is having with the content source that you are troubleshooting. The Fiddler web site has many resources for evaluating the results. Of course you could use this technique with other HTTP proxies, like WireShark, but I find Fiddler to be the easier to deploy and use in most scenarios.

Troubleshooting SharePoint Search can be a challenge. I hope that the techniques that I demonstrated here enable you to be more methodical in your efforts to determine why a crawl is failing and more efficiently find the resolution to the problem.

When I first started working on SharePoint Search I was troubled by how hard it was to figure out what was actually happening when the crawl was running. The crawler/indexer is a black box that I could not see into. This made it very challenging when I would open the crawl logs and see a cryptic error message. (Often the cryptic message is not the fault of SharePoint Search, the log is just bubbling the error up, often from the iFilter.) Here are two approaches that I use to troubleshoot specific errors. The first is a tool for troubleshooting iFilters the second for watching the actual crawl activity.

iFilter Troubleshooting

The SharePoint Indexer uses special assemblies called iFilters to open files and extract the metadata and plain text during the indexing process. The filters for many common file types are installed by default when the SharePoint Prerequisite Installer runs. Additional iFilters can also be purchased from dealers like Foxit Software and the IFilter Shop. Recently I was troubleshooting an issue where a client was seeing errors in their crawl logs for PDF files. They had installed and licensed the PDF iFilter from Foxit Software. Running the crawl caused the error “Error loading IFilter: E_INVALIDARG” to appear for every PDF file. This is how we determined the root cause.

1. Download and run IFilter View from IFilter Shop (http://ifiltershop.com/downloads/IFilterView.zip). You have to run this tool on the SharePoint box that is running the index process. This tool loads the iFIlter for the files that you are troubleshooting.
2. Select the file that you are having trouble with by choosing File | Open. In my case I chose a PDF file. If the file is in SharePoint, simply copy it to the desktop of the server for troubleshooting.
3. If the file loads properly, the issue is with SharePoint. If the file fails to load, the issue is with the iFilter. In our case we saw the identical error. To us this indicated an issue with the iFilter.

   

4. It turns out that the license key file was improperly deployed. Once we determined that with the help of the folks at Foxit Software we reran IFilter View and got the results we expected.

   

IFilter View is also very handy for determining the names of Crawled Properties returned by the iFilter. I detail this process in the post “Troubleshooting iFilters and Crawled Properties” (http://www.ableblue.com/blog/archive/2011/09/28/troubleshooting-ifilters-and-crawled-properties/)

Tell SharePoint to Include the Crawled Property in the Index

So we needed to tell SharePoint to index the Keywords crawled property. HTML META keywords are indexed as “Office:5(Text)” and mapped to the DocKeywords managed property. Open the crawled property Office:5(Text) (the one with the GUID f29f85e0-4ff9-1068-ab91-08002b27b3d9 not the one with the GUID d5cdd505-2e9c-101b-9397-08002b2cf9ae) and check the box labeled “Include values for this property in the search index”.

Re-crawl the content and the search for “Elephant” will be successful.

I don’t want to see the Keywords

So now the problem is that the Keywords are showing up in the Hit Highlighted Summary for the search result. Now you might like that, but we didn’t. We wanted the hit, but did not want to see the keywords, they were only there to help with findability, but they did not help readability of the summary. The solution is to add the fields that you wish to exclude from the summary to the ExcludeFromSummary managed property. Open the Managed Property for ExcludeFromSummary and add the first Office:5(Text) property in the list.

Re-crawl the content and you should still get a search hit, but you should not see the field in the Hit Highlighted Summary.

Cheers!

• Working in the Web Part XSL dialog is an error prone exercise
• Moving the XSL to the Style Library allows you to maintain versions of your XSL
• SharePoint Designer will Syntax Highlight your XSL

Here are the steps I follow:

Get the XSL out of the Web Part

The main goal is to get a working version of the Search XSL out of the Web Part for you to work with in SharePoint Designer.

1. Open your search results page in a browser.
2. Put the page in Edit mode and choose Edit Web Part from the Search Core Results Web Part menu.
3. In the Search Core Results Tool Pane open the Display Properties section. Uncheck Use Location Visualization and the XSL Editor… button should become active.
4. Click the XSL Editor… button to open the Text Editor dialog.
   
5. Right click in the dialog and choose Select All. Copy the text and paste it into Notepad++ or other text editor and save it. I do this step because I like to preserve the original XSL as I have seen cases (usually when I am conducting a demo, where the dialog open up totally blank. I like to have a copy for safe keeping.
6. Click Cancel to close the dialog.
7. Open SharePoint Designer to the root of the site collection hosting the Search Center. Under Site Objects click All Files and browse to the XSL Style Sheets folder, the path from the root is /Style Library/XSL Style Sheets. (You can actually put them anywhere your visitors have read access. I have always used the XSL Style Sheets folder.)
8. Right click on the XSL Style Sheets folder and choose New | CSS. (I know! If there was a New | XSL option I’d have you choose that…)
   
9. Provide a sensible name for the file. I usually use something similar to the name I gave the results page. Be sure to change the file extension from CSS to XSL. When SPD warns you about changing the file extension choose Yes, you do want to change it.
10. Right click the new file and choose Edit in Advanced Mode. SharePoint Designer will open the blank file.
11. Paste the XSL that you copied from the Web Part dialog into the file. Save the file. (Look! Syntax Highlighting!)
    
12. In the All Files pane right click the file and choose Check In. Choose the Publish a major version radio button and provide a comment that indicates this is the original XSL from the Web Part. Choose OK to check in the file.
    
13. Right click the file again and choose Properties. Copy the contents of the Title text box. Choose Cancel to close the dialog.
    
14. Return to the browser (you should still be in Edit mode, if not edit the Search Core Results Web Part). Expand the Miscellaneous section. In the XSL Link property add a backslash and paste in the Title path that you previously copied from the XSL file.
    
15. Click OK to close the Web Part Edit Pane. Choose Check In from the ribbon. Provide a comment and choose Continue.

At this point you should be able to execute a query from your search results page and see search results just like the result you get with the out of the box results page. Go ahead and give it a try. If the page explodes, retrace your steps and see what you did wrong. If it’s all working then lets try to edit the XSL and make a noticeable change so that we are REALLY certain that the Web Part is reading our file. NOTE: Since we are using Check Out and Check In you have to be viewing the Search Results page with the same account that you are using to edit the XSL.

Edit the XSL

I usually start by making a simple, subtle change to the page so that I am sure that the XSL is working. I do the following:

1. Return to SharePoint Designer, right click the file and choose Check Out. Right click the file and choose Edit File in Advanced Mode.
2. Locate the line in the Result template that displays the metadata. Locate the tag <div class="srch-Metadata2"> and add a noticeable word to the end of the line, like this: <div class="srch-Metadata2">Willa
   
3. Save the File (you don’t need to check it in.)
4. Refresh the Search Results page and you should see the word on the page before every Author (or Date).
   

Now you KNOW that you own the XSL. You can use SharePoint Designer to make the changes you need and use SharePoint for version control. How great is that? If you work on complex XSL and need to roll back after a small change breaks your page, you will find it a life saver!

One Word of Warning

Back in SharePoint 2007, if you messed up the XSL for the Search Results you would get a huge error message telling you so. In 2010 the Search Core Results Web Part is “Self Healing”. In other words, if you screw up, it will not tell you. The Web Part will just load it’s own copy of a working stylesheet and present the user with Search Results. You can easily demonstrate this:

1. Return to SharePoint Designer and make a simple, albeit catastrophic, change to the stylesheet. On the line below the edit we made above, remove the closing greater than sign just after “DisplayAuthors”. Making the line that reads <xsl:call-template name="DisplayAuthors"> read <xsl:call-template name="DisplayAuthors".  Notice that SharePoint designer flags this error in yellow on the following line. (I used to do this demo by gutting my stylesheet, deleting 20-30 lines, but this is more realistic and subtle.)
   
2. Save the broken file.
3. Return to the Search Results page and refresh the browser. You should notice that the text we inserted is removed and no error is generated.
   
4. Depending on your perspective this is either a good thing or a bad thing.
5. Return to SharePoint Designer and undo the last action. Save the file and refresh your browser, you should see the text return.

I call attention to this feature because I have run into it so many times that it is the first thing I troubleshoot when we are having Search Center issues. I hope this save you some grey hair.

• I want to extract XMP data from images like Latitude and Longitude
• I need to promote a particular field for use as Document Keywords
• I need to troubleshoot a specific iFilter

Time and time again I have evangelized the use of supported third party iFilters like the iFilter Shop and their great selection of products to solve indexing challenges (rather than free crap). Likewise, I LOVE the Foxit Software PDF iFilter. In tests the multithreaded Foxit iFilter 2.0 CRUSHED the Adobe iFilter by indexing files 39 times faster than Adobe (processing a scorching 29 files per second). Read the full review. But what happens when you decide to use these tools and the results are not what you expect, or you want to take the plunge and extract more metadata, like the XMP file information from an image? The reality is that the SharePoint Crawled Property interface are not very "user friendly”. I hope to change that with the help of our friends at the iFilter Shop and some recent experience.

Crawled Properties

I will be the first to admit that my eyes cross when I get into the Crawled Properties page. You get there by navigating from Central Administration to your Search Service Application and choosing Metadata Properties from the left navigation. Then from the tool bar choose Crawled Properties. It is cryptic and obscure with properties like Basic:10 (Text), Category 8:100 (Integer), and, occasionally, something human readable like SharePoint:ows_City(Text) and People:AboutMe(Text). Figuring out the SharePoint properties is not too hard. If the property begins with “ows_” it usually came from a field in a list or library. So if I create a list and add my own field called “DogBreed” and then crawl the list, I’ll see ows_DogBreed show up as a crawled property. What about the other properties? Well, when the crawler finds a document, web page, BCS data or what ever, it passes the item to the registered iFilter for that item. The iFilter “reads” the item and extracts the metadata properties and text. So don’t blame SharePoint, it is just cataloging what the iFilter provides. If the iFilter returns a property and calls it Basic:10 of type Text, SharePoint makes not of it exactly that way. It ain’t pretty, but it works.

Getting to the Properties

So, what about all the other fields with significantly less descriptive names? Names like Office:3 and Office:5? What the heck is that? Well, using a very cool tool from the iFIlter Shop, I will attempt to explain. But first a little background on where properties come from… For example, I have a Word document that has metadata. How do I know this? Because I can right click the document and choose Properties and view the metadata on the Details tab.

Of course, since I have access to the document I can also view the properties in Backstage.

PDF documents have a similar properties dialog and you can access them from the file system or through the File | Properties dialog. Here is a document I created by scanning a recent news article about my dog Willa.

And the corresponding file properties in Windows 7. Notice that, unlike the Word document, there are fewer document properties available in the Property dialog from the operating system.

So how do we get Title, Subject, Author and Keywords if the OS cannot? Simple, iFilters.

Property Extraction

The problem I determined was this, How do I make the process of Crawled Property (with a cryptic name) to Managed Property (with a name of my choosing) a predictable experience? How can I “see the file the way the iFilter sees it?” That is where the folks at the iFilter shop came to the rescue with their free tool, iFilterView. First, download iFilterView from iFilter Shop. This tool is purpose built to show you what the iFilter sees when it opens your document. Once downloaded run it and choose File | Open and choose a file, in our case the first Word document. Notice that the output shows some of our properties. Notice the Property IDs like 2, 4 and 5. They look familiar. They look like the Title, Author and Tags from the first example above.

Lets do it again, this time on the PDF. Yep, Title, Subject, Author and Keywords.

I see that we’re getting somewhere, if only there were some identifier, some global identifier that tied our property as extracted by the iFilter to our Crawled Property as registered by SharePoint. If only…

Making the Connection

If you really dig into crawled properties (by simply clicking on one) you will see that there is more information hiding under the covers. In my case I chose Office:4 (Text).

This page shows the wildly verbose Property Name, and the Property Set ID. Notice that the Property Set ID relates exactly to the ID in the iFIlterView dump of the property 4 above. So here is my ah-ha moment. If I don’t know what the property is, I can add it to a document, open the document in iFilterView and observe where my property ends up and then look in SharePoint for the GUID. How cool is that?? Now I know that Office:4 is mapped to the Managed Property Author.

Did I Mention GPS Data?

You can extend this to new iFIlters like the XMP iFilter from iFilter Shop. If I have a photo with XMP metadata, I can open it with iFIlterView and look at the GPS Data. This takes the guess work out of configuration. Now I know what to look for in the Crawled Properties interface, I’ll find two properties GPSLatitude and GPSLongitude. Waiting for me to map to managed properties.

Needle in a Haystack

OK, so when I said “All you have to do is find the GUID” how many of you cringed? OK, probably only those of you who have actually spent more than 15 minutes looking at crawled properties. Trust me, it is tedious. There has to be a short cut! Well I have been trying to absorb my friend Gary Lapointe’s amazing book Automating Microsoft SharePoint 2010 Administration with Windows PowerShell 2.0. I decided to write a script to dump all the Crawled Properties so that I could just search for the GUID in NotePad++. Blame me for any errors, not Gary, he’s innocent, really, really innocent, I mean, have you met the guy?

Anyway, the following code will enumerate all your categories and Crawled Properties and create an XML file that you can search for your GUIDs. You just have to change the $ssaName constant to match the name of your Search Service Application.

## Test and Load the Microsoft.SharePoint.PowerShell Plugin
if (-not (Get-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue)) {
    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
	if (-not $?) {
		Write-Host $error[0].Exception.Message -ForegroundColor Red -BackgroundColor Cyan
		return
	}
}

#Change this to match your SharePoint Search Service Application name
$ssaName = "Enterprise Search Service Application"

$ssaID = Get-SPServiceApplication | Where-Object {$_.Name -eq $ssaName}

#Get the search application
$searchapp = Get-SPEnterpriseSearchServiceApplication $ssaID
#Get the CrawledProperties
$categories = Get-SPEnterpriseSearchMetadataCategory -SearchApplication $searchapp

# Convert to XML
1$xml = "<categories/>"

#Loop and return all Properties
foreach ($category in $categories)
{
	#Create the new node
    $categoryElement = $xml.CreateElement("category")
	$categoryElement.SetAttribute("name", $category.Name)
	$categoryElement.SetAttribute("count", $category.CrawledPropertyCount.ToString())
    #Add the XML
    [void]$xml.DocumentElement.AppendChild($categoryElement);
	Write-Host 'Writing Category ' $category.Name

    #Add a properties Node
    $propertiesElement = $xml.CreateElement("properties")
    [void]$categoryElement.AppendChild($propertiesElement)
    #Get the Crawled Properties for the Category
	foreach ($property in $category.GetAllCrawledProperties())
	{
        #Create a Property node
        $propertyElement = $xml.CreateElement("property")
        [void]$propertiesElement.AppendChild($propertyElement);
        #Set the Attributes
		$propertyElement.SetAttribute("name", $property.Name)
		$propertyElement.SetAttribute("propset", $property.Propset.ToString())
		$propertyElement.SetAttribute("varianttype", $property.VariantType.ToString())

	}

}

$xml.Save("$home\crawledprops.xml")

Are We Done?

No, we’re just getting started, but I need to save that for another post.

We are also giving away over 120 SharePoint books at our booth with hourly book drawings and eight book signings throughout the week!!!

But wait, that’s not all… we’re also giving away over $25,000 in SharePoint training to lucky winners throughout the week.

Where can you get more info? Check out our October community page on our website: http://www.criticalpathtraining.com/Community/Pages/October.aspx

Looking forward to seeing everyone… make sure you come to the ESPNZone on Wednesday night for SharePoint by Day, SharePint by Night!

Some of my favorite demonstrations are about how to enhance the Search Results pages in SharePoint. I feel that presenting “actionable” search results can make the difference between a good search center and a great search experience. I am working on some new demos and decided that I need to commit the fundamentals to my blog so that my audience has the necessary resources to apply the guidance from my presentations.

I always use the “Enterprise Search Center” also known as the “Search Center with Tabs”. I find that the UI lends itself to customization and branding far better than the “Basic Search Center”. The first issue you will face is creating a new tab in the UI and associating it with a page. This initial step can be confusing. So I’ll walk through it with you. One other annoyance is that the tabs can be challenging to reorder. At the end I’ll review a hack that I found that helps you reorder the tabs in the SharePoint Search center.

Understanding the Tabs

The first thing to understand is the Tabs. There are two lists that control the Tabs, one for the Search pages and one for the Results pages. If you want the same tab on both types of pages you have to configure the links in BOTH lists.

If, while editing the Search Center, you click Add New Tab, you will be directed to the list associated with the page type you were editing (Tabs in “Search Results for Search Results” pages and “Tabs in Search Pages” for Search pages). This means that you can display different tabs on the Search Results pages than you do on the Search Pages.

In each list the Tabs are related to a page. The page is displayed when the tab is clicked. This means that you have to create the page first, before creating the tab.

Create the Results Page

If you are on your Search site and you click Site Actions | New Page the default configuration is to create a Search Results page. This means that if you want to create a new Search page you have to take the long way around. For this reason, I always create my pages as follows:

1. Choose Site Actions | View All Site Content.

2. Choose the Pages library.

3. From the ribbon, choose the Documents tab and choose New Document | Page.

4. On the Create Page page enter the Title and Description for your new page.

5. Enter the URL. I use a standard page name that ends with “result”, like “demoresult”, “videoresult” for my results pages.

6. Finally, choose the type of page that you want to create. For this demo, choose Search results. Usually you will choose one of the following page types:

· Search results

· Search box

· People search results

· Advanced Search

7. Click Create.

8. You will be returned to the Pages library and see your new page listed.

9. Click the link for your page to see the new page you created. Since there is no query you will see the text “No results are available. Either no query is specified, or the query came from advanced search (Federated Webparts do not support Advanced Search queries).” Don’t fret. If you got this far you are doing great.

Fix the Page

The next step is to “fix the page”. Now, it’s not “broken”, but it does display some odd behavior if you try to use it. For example, enter a query and click the search button. Go ahead, I’ll wait. Look at the search results page URL. Notice that it is no longer your new search page, it’s the default Search site results page. The reason for this is because the web parts on the page are wired for the default search center. We have to change that behavior. Use the back button to return to the new search results page you created and follow these steps:

1. From the ribbon, choose the Page tab and choose Edit.

2. Select the Search Box Web Part and from the context menu on the Web Part, chose Edit Web Part.

3. In the Search Box Web Part properties pane, open the Miscellaneous section and change the Target search results page URL property to the name of your new search results page. My page is called DemoResults.aspx.

4. Click OK in the Web Part edit pane.

5. Choose Save & Close from the ribbon.

6. Test your work by entering a keyword in the search box for your page. You have done it correctly if your search results show up on your new page. In my case I entered my keyword on the demoresults.aspx page and my results are showing on the same page.

Add a Tab

OK, now that your page is working we can add a tab. Since this is a Search Results page, we’ll add the tab to the “Tabs in Search Results” list. You can do that by returning to All Site Content or you can do it from the page.

1. From the Search Results page, choose the Page tab in the ribbon.

2. Click Edit.

3. On the page choose Add New Tab.

4. Enter a Tab Name (this is what the User will see).

5. Enter the exact Page name of your new page. In my case it is demoresults.aspx.

6. Enter a Tootip for the user to see when they hover over the tab. This will let them know what they’ll get by clicking the tab.

7. Click Save. You will be returned to the search results page and you should see your new Tab highlighted. (If not refresh your browser once or twice.)

8. Test the tabbing by entering a query on the All Sites tab. Click the search button and review the results. Click your new tab and you should see the same results on the new tab. If you get an error it is usually because you spelled the page name wrong in the Tab entry.

Reorder the Tabs

Back in 2007 the Tabs list supported reordering. I noticed in 2010 that the Change Item Order button is missing from the Tabs list. The list still supports it, but you have to cheat a little to get it right. Here is how I have found you can reorder the items in the Tabs list. Note: Your mileage may vary.

1. Browse to the Tabs list you want to reorder. Site Actions | View All Site Content. Choose Tabs in Search Results for this demo.

2. From the ribbon choose List from the List Tools group. Choose List Settings.

3. Edit the URL and change the page reference from listedit to reorder, leave the rest of the entire URL.

4. You should see the Change Item Order page where you can now change the order of the Tabs. Set the desired order for your tabs and click OK.

5. Return to the Search Results page and…it did not change a thing. L Return to the Tabs in Search Results list and notice that they are reordered. For some reason the Search Center control is unaware that we made the change.

6. Open and edit ANY item in the list. I edited the XML record and changed its name to XML. Click Save.

7. Return to your Search Center and the results page should reflect the desired order of the Tabs.

Conclusion

I hope that this walk through helps you get started on the road to creating great search center results pages. What I reviewed here is just the basics. In later posts I’ll cover how to edit the results XSL and how to debug the XSL in a reliable and repeatable way.

Microsoft unveiled the SharePoint 2010 and Windows Phone 7 Training Course! If you are looking to create Windows Phone 7 mobile applications that integrate with SharePoint this is the kit for you. This kit was developed by Darrin Bishop, Todd Baginski, and myself. We also worked very closely with Paul Stubbs, Dave Pae, and several engineers at Microsoft throughout the project. Without their help, guidance and willingness to dive in on problems we never would have finished!!

The kit takes a soup to nuts approach that begins by showing you how to set up a Windows Phone 7 development environment and eventually ramps up to some very complex functionality such as how to integrate with SharePoint and Windows Azure.

In the kit, you will find a total of 25 labs that include step by step instructions and sample source code. Look at a sample of what you can learn!!!

Integrating SharePoint and Windows Phone 7 using Web Services

Integrating SharePoint and Windows Phone 7 using Rest APIs

Integrating SharePoint and Windows Phone 7 using Syndication Feeds

Integrating SharePoint Social Web Services and Windows Phone 7

Paging SharePoint List Data using Web Services and Windows Phone 7

Integrating Images Stored in SharePoint with Windows Phone 7 using Web Services

Uploading Images to SharePoint using Windows Phone 7

Integrating SharePoint and Windows Phone 7 using Forms Based Authentication

Integrating SharePoint and Windows Phone 7 using Unified Access Gateway (UAG)

Integrating SharePoint and Windows Phone 7 Notifications

Integrating SharePoint and Windows Phone 7 Tile Notifications

Integrating SharePoint and Cloud Services in Windows Phone 7 Applications

Integrating SharePoint and Cloud Data in Windows Phone 7 Applications

Integrating SharePoint with Cloud Services and Data in Windows Phone 7 Applications

Integrating SharePoint and Windows Phone 7 in Offline Mode

Integrating Windows Phone 7 Applications with SharePoint People Data

Querying the List Schema for Choice Fields

Creating Private Windows Phone 7 Applications

Creating Private Windows Phone 7 Applications That Use Service Based Security

If you have been craving some development with Windows Phone 7 and SharePoint together, here is your chance!

Do you have tough technical questions regarding SharePoint for which you’re seeking answers? Do you want to tap into the deep knowledge of the talented Microsoft Most Valuable Professionals? The SharePoint MVPs are the same people you see in the technical community as authors, speakers, user group leaders and answerers in the MSDN and TechNet forums.

By popular demand, we have brought these experts together as a collective group to answer your questions live. So please join us and bring on the questions! This chat will cover WSS 3.0, MOSS, SharePoint Foundation 2010 and the SharePoint Server 2010. Topics include setup and administration, design, development and general question.

Please join us on Wednesday June 22nd at 9am PDT to chat with MVPs from around the world. Learn more and add these chats to your calendar by visiting the MSDN event page http://msdn.microsoft.com/en-us/events/aa497438.aspx

You can follow the Tweet-stream on hashtag: #spmvpchat