Here is a bullet point point version of the good and bad on the current status of Office 365 integration after speaking to a Yammer sales guy this morning. There is also an interesting article here.

The current integration with Office 365 is a myth. While there is some basic visibility into Yammer, they are still essentially 2 different networks. So for now the free Yammer account will be fine for most people.

In 6 weeks this will change and the Yammer feed will replace the SharePoint feed. Let’s see if that happens on time.

This will only happen if you have an Enterprise Office 365 (E1-E4) account already and will cost $3 per user per month and no being a Microsoft Cloud partner doesn’t entitle you to free Yammer Enterprise accounts! WTF?

This part amazed me the most. To sign up to Yammer requires a written contract that they send you and you need to sign up for 1 year. For a technology company that is pretty lame. Obviously 1.2 billion doesn’t buy customer service like it used to.

Please Note: That the only reason we need to do this is because we are still on the old version (2010) of O365. In June they would have upgraded our system to 2013 versions and we wouldn't need to transfer our mail manually when going form a P3 to E3 plan.

This tool makes the migration a breeze. You simply:

create a connector between your old mail system and the new one (You will need to be an admin on both systems)

Specify the mailboxes to copy across and start copying

Benefits

Very easy to use

The support is great and very responsive

It does multiple passes of the mail so that if during transfer more mail comes in, it will be picked up on the next pass

Things to watch

Don’t use your main email address as the connector admin account. If using O365, use the onmicrosoft accounts they provide. These email addresses are unique to each account so when you transfer the MX records across you can still keep transferring in the background.

Large accounts can be slow to transfer. In the screen shot above you can see that we have 2 15 gig accounts that will probably take a week to transfer. If set up properly though you can start using your new account straight away as it copies newer mail first.

Next I’ll be looking at transferring content from our internal SharePoint to Office 365.

Cloud based services are becoming more popular as more organisations recognise the costs savings that come from letting someone else manage your software and infrastructure. So what does it mean for companies wanting to deploy SharePoint in the cloud?

The Cons

There is a minimal custom SharePoint Development allowed. Forget third party add-ons or customising the look and feel too much

It won’t be as fast as an in house system. Especially when uploading and downloading documents

You can’t integrate it with other systems you have on premises

You need to run Federated Active Directory services so that your users can be imported into SharePoint

Conclusion

If you are a small company that just needs the built in SharePoint functions and isn’t concerned about the look and feel of their site and especially if you don’t have in house IT support then Office 365 is probably a good solution.

If you are a larger organisation who’s needs may grow to require custom functionality then we wouldn’t advise at this point. Plans start at approx. $8 per user per month and go up significantly depending on your plan so it is cheap if you only have a few users.

Recently we came across an issue with our SharePoint 2010 people search. It did not work. The All Site scope worked fine but the people search scope did not return any results. We were using SharePoint 2010 FAST search.

The people scope with FAST search was in FAST Query SSA (How does People Search work using Fast?). We needed to look at the FAST search configuration in Central Admin: Manage Service Applications >> Service Applications

We made sure that the Content Sources of the FAST Query SSA had the Start Address set to: sps3://<server name>

We run a full crawl on this content source. At the end of the crawling process the Crawl Log had one Error: Access denied ..

The Crawler could not access the User Profile. To solve this we needed to allow the crawler access to the User Profile Application. This was done through - Manage Service Applications >> Service Applications >> User Profile Application. Then add the permission “Retrieve People Data for Search Crawlers” to the account which run the FAST Query SSA.

This tool came highly recommended for performing diagnostics. We used SharePoint Diagnostic Studio for connecting to SharePoint 2010 logs. This tool run with Administrator privileges only (right click – Run as administrator )

The goodie – This tool could save looking into the file system. It came with some SharePoint 2010 reports – that looked impressive.

The baddie – It took several minutes to connect. It did not refresh the logs and needed to re-open to reload new logs.

The Clue:

Someone suggested we look into the SharePoint lists to make sure they were working. We clicked on each list and library until we discovered the corrupted list.

One list returned the SharePoint 2010 error page. How could we remove this list if we could not access it? We tried accessing it from SharePoint 2010 Designer but it did not appear under All Files/Lists. We tried removing it using SharePoint Manager 2010 but received an error message.

This is the error we got when trying to delete the list: Error log "Failed to determine the setup path of the list schema for feature {123546-423432}, list template

The Solution:

SharePoint 2010 Management Shell (PowerShell).

First we looked for this feature on our site: Get-SPFeature | Sort - Property Id

This feature was not on our site. Clearly, SharePoint told us already that this feature was missing.

We had to remove the list with force, using PowerShell delete command:

So instead of rewriting what he said I hope to add something by providing a worksheet that I have been working on. It’s really in Alpha so if anyone can improve on it and share what they have done that would be great.

Although SharePoint provides the ability for users to be able to tag their own content, I find it tends to get a bit unmanageable and like to stick to the “Managed Metadata” feature with hierarchical predefined tags.

Here are my guidelines for tagging:

Think long and hard about your top level tags. You shouldn’t need more than 10 at most and there should be as little cross over as possible. Again don’t have more than 10 items per each individual branch.

When deciding what the tags should be, think of words that will segregate content into even chunks. Don’t create a tag that will only ever be used once. Think of the game Guess Whowhere you are trying to find the person in as few guesses as possible. You don’t start with some obscure physical feature. The first question is usually - Are you a boy (or girl) to split the content evenly.

Try not to go more than 3 levels deep in the hierarchy at first, including the top level. You can always add further levels if drilling that far down still displays too many articles.

Don’t use words that are going to change often such as names of clients or projects. The list will eventually get too long to be useful. In this case it may be easier to keep a list of all clients in a custom list that is referenced through a site column.

So you wants to add an event receiver to a list to check column permissions. Your immediate reaction will be “easy no problems, I’m keen to start now”. Consider all the implication of this task. I thought initially, event receivers in SharePoint 2010 should be easy to implement. But then I learned that there are many “things” to know for this task. I decided to prepare a list with all the road blocks I encountered during this project.

Here are some tips for creating a new event receiver in SharePoint 2010:

2. You want your receiver to work on a specific list, not on a list type. Your element.xml should fix it: <Receivers ListUrl="<List Name>">

3. You want to make sure that the receiver is deployed as a farm solution. If we select Sandbox solution, this option is very restrictive and does not allow access to certain SharePoint features. So click on your project and view the properties window (F4). Then set “Sandbox solution” to “False”.

Also if you want to deploy to a single site use “Site URL” in the properties menu.

4. To deploy and package your solution you can use “Deploy” and “Package” in the Visual Studio 2010 on project’s right click. Do not use the WSBuilder sub menu.

5. To debug use the WSBuilder sub menu and select “Attach to IIS Worker Process”, then enter your breakpoints.

6. I wanted to make sure that system admin have full permission: using (SPWeb currentWeb = properties.OpenWeb()) { if (currentWeb.CurrentUser.IsSiteAdmin) return; }

7. You want to add debugging information to your code. This is another reason why you should not use sandbox solution. Consider these quotes: Dashboard diagnostics: “Even if you use SPMonitoredScope, if your code is a sandbox component (i.e. a User Solution), the output from it will not be captured in Developer Dashboard. The reason it doesn’t get captured is that sandbox components execute in a completely different process from the page request – that’s why it’s sandboxed” Log diagnostics: “Unfortunately the ability to interact with a custom SPDiagnosticsService is available only in fully trusted farm solutions and not within sandbox solutions. To write to the ULS logs using the SPDiagnosticsService class from the sandbox, developers can create a fully trusted proxy that the sandbox solutions can call into. The next two sections demonstrate how to write to the SharePoint ULS logs.”

But all is not lost, you can still save to SharePoint Log: using Microsoft.Office.Server.Diagnostics; PortalLog.LogString(“Message”);

8. The example I prepared is for firing an event when updating an item: public override void ItemUpdating (SPItemEventProperties properties) { base.ItemUpdating(properties); TakeAction(properties); }

9. Sometimes you may need to active/deactive your feature from the site collection.

10. You definitely want to have a custom error page to indicate your user that something happened. You can learn how to create a custom error page from here. For example: properties.Cancel = true; properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl; properties.RedirectUrl = "/_layouts/<folder name>/<>page name.aspx?error=Update failed.";

11. The message in DataSheet view is not as you expected. I have no solution for making a nicer error message.

12. Using the properties.AfterProperties you want to determine if the item has been modified during this update. Consider what I had to do to get the correct column: string internalColumnName = XmlConvert.DecodeName(properties.List.Fields.GetField(columnName).InternalName); if (properties.AfterProperties[internalColumnName] != null) newValue = properties.AfterProperties[internalColumnName].ToString();

Yes, there is a different name for the list column displays and the actual SharePoint column name. This is especially true if you rename an existing column The XMLConverter decode columns names , e.g. Date_x0020_Modified. This link has good explanation.

13. For security reasons, a SharePoint designer workflow always runs under the permissions of the user who started the workflow. You want to prevent the user from updating certain column in the list, but you also want your SharePoint Designer workflow to update the same columns. Two possible solutions, you can use a hidden field to indicate to the event receiver that the workflow is updating the field. You can toggle the hidden field before and after the item update. Another solution is to us user Impersonation Step and run the workflow as farm account. The second solution may not be your preference, because it will save the “Modified By” as the farm account.

These are the 13 new knowledge points which I gained during this project.

Webcoda, SharePoint Consultants & Web Development

We can't tell you their names or show their faces on TV but if you need a SharePoint job done right, call them on +61 2 9370 3602 or email us at info@sharepointsydney.com.au

Persecuted by the Government and shunned by society they developed their SharePoint skills in back streets and labor camps where other programmers wouldn't dare to tread.

During a trek through the Himalayas they stumpled upon the fabled Mossy Yak who shared his SharePoint knowledge of how to attain Nirvana through a series of Workflows and Event Handlers. Their mission is to spread this knowledge through-out the world to bring peace, harmony and document version control to all .