I believe that when the topic of duplicate content comes up it generally revolves around content discovery, primarily the impact that duplicate content has on search results. While duplicate content is quickly pegged as the culprit, it’s really more of a discoverability issue around authorative content. Removing duplicate content may not really be the solution, but perhaps effectively surfacing authorative content by reconfiguring search result page(s), fine tuning your search configuration, and doing a better job leveraging refiners and scopes.

As a user who sometimes copies documents and presentation from other areas into my own collaboration or personal sites, I wouldn’t be in favor of a solution that automatically removes my copies. I believe that in trying to remove duplicate content, you’ll quickly find many such users, and you may ultimately find yourself trying to change too much about how your users get work done.

Of course, discoverability may not be the issue you are trying to solve with de-duplication, in which case it may ultimately have to do with storage. If so, it may point to a bigger issue around information architecture, lifecycle management, and content expiration… But I’ll leave those topics for another time in the interest of keeping this posting short.

As far as the differences between the ActivityEvent.Owner and ActivityEvent.Publisher, we need to take a quick step back and reflect on the overall activity feed architecture; specifically how each activity event propagates and how each user ultimately has their own activity feed. In essence, if I generate an activity such as tagging or liking a document, that activity event gets created in my activity feed; but it wont appear on my colleagues activity feeds until its been propagated (in a way duplicated,) to their personal activity feed.

So with that in mind, when an ActivityEvent originates, the publisher and owner would probably the same; it first get created in the originating users activity feed (hence that user owns it), and he/she is also the person that performed the activity (the publisher.) Once the activity propagates to another users activity feed, such as that of a colleague, that other user would be designated as the owner of the newly created (propagated) activity (its in their personal feed), while the publisher would remain the originating user.

There is a migration guide for each of the core Office products; Outlook, Word, Excel, PowerPoint, OneNote, and Access. Each put together based on feedback from users.

Check them out at: http://office.microsoft.com/en-us/excel-help/office-2010-migration-guides-HA101982272.aspx

What you probably haven’t heard, is that the Office 2010 Web Apps are also available in Facebook via the “Docs” application; from where you can easily create, upload, and share your MS Office documents (Word, Excel, PowerPoint) with your friends, or everyone for that matter.

You can even designate your friends as editors, and collaborate on documents, worksheets, or presentations. Once you are done, you can easily post it to your wall and share with everyone. All via your Web Browser.

I’ve uploaded several presentations to “My Facebook Docs” for you to check out (you must be logged in to Facebook).

Check out the posting at:

http://blogs.consumerreports.org/electronics/2010/07/apple-iphone-4-antenna-issue-iphone4-problems-dropped-calls-lab-test-confirmed-problem-issues-signal-strength-att-network-gsm.html

While most of the configuration of managed accounts will likely take place in Central Administration, at some point you may need (or simply prefer) to change the password via PowerShell. Personally, I ran into the need, as my farm account password had been changed and the Central Administration site would not run.

I used the following PowerShell script to change the Managed Account password.

$ver = $host | select versionif ($ver.Version.Major -gt 1)  {$Host.Runspace.ThreadOptions = ReuseThread"}Add-PsSnapin Microsoft.SharePoint.PowerShellSet-location $home

$inManagedAcct = Read-Host 'Service Account'

$managedAcct = Get-SPManagedAccount $inManagedAcct

$inPass = Read-Host 'Enter Password' -AsSecureString$inPassConfirm = Read-Host'Confirm Password' -AsSecureString

Set-SPManagedAccount -Identity $managedAcct -NewPassword $inPass -ConfirmPassword $inPassConfirm -SetNewPassword

Click here to download the PS1 file. You may need to remove the first few lines that load the SharePoint PowerShell snap-in, if you intend to run the script from the “SharePoint 2010 Management Shell” console.

Outlook will automatically let you know that you will receive an “Automatic reply” from the moment you specify the recipient.

Its these little details that make all the difference.

Security is one of the most important things to consider when connecting to external systems using Business Connectivity Services, and this article is a great place to get started. Check it out at: http://blogs.msdn.com/bcs/archive/2010/03/12/authenticating-to-your-external-system.aspx

One such feature is the “Share” menu, with the option to “Save to SharePoint”. The following screenshot is from the MS Word 2010 Menu after creating a brand new file… complete with Recent Locations.

May not seem like much, but try living without it after you’ve had it for quite some time.

True, we’ve had “My SharePoint Sites” within the “Save File” screen in previous versions. But its never quite worked as expected… you had to explicitly be a “Member” of the site (not through an AD group), the profile import had to be working just right, after you were made a “Member” of the site it may not have shown up on your list until the following day, and a slew of other things. You could also say that we had “My Network Places”, but that required a certain level of proactivity that often times you just don’t have.

Nothing in Office 2010 was my idea… but to whoever’s idea this feature was; Thanks for keeping my experience in mind.