OT: Mountain Lion + SkyDrive Error

For those that use Mac OSX with VMWare and other products to perform their day to day SharePoint work – props to you for working a little outside the box.

On a side note, if you decided to upgrade to Mountain Lion quickly after it was released, it appears that you beat Microsoft to the punch of providing a fix for SkyDrive to operate properly. Upon first boot up, you’ll probably get a nice little error message stating that the SkyDrive app can’t authenticate to the KeyChain. Mild issue… actually major issue unless you want to use your favorite HTML5 enabled web browser to grab and drop files back and forth between the desktop instead of through Finder integration.

Nevertheless, there’s a work around that I found after seeing Talbott Crowell post something on Twitter earlier today. In the Microsoft forums, an answer was posted here http://bit.ly/PNvIw1 (shortened for consumption). It effectively says to do the following with the note at the beginning as a temporary work around if you really need SkyDrive before a full up fix is provided:

Thank you for reporting the issue, we are aware of the problem and working to get it fixed ASAP.

For now the only workaround is to change the properties in the SkyDrive’s cached credential item to allow access from all apps:

Launch “Keychain Access” from /Applications/Utilities
Select the login keychain from the list
Locate the “SkyDrive Cached Credential” item and select it
Go to “File/Get Info” (Command + I)
Go to “Access Control” tab
Click to select “Allow all applications to access this item”
Click “Save Changes”
NOTE: The “SkyDrive Cached Credential” item is created after you sign-in for the first time.

Automation of Password Updates…

Recently I stumbled upon a SharePoint 2010 environment setup a long time ago where the managed accounts and accounts in general were setup a little funny… in particular the issue was that the profile service stopped syncing. I asked the administrator what the issue was and they stated that they’d setup the system to use a managed account for the farm service account and other service application service accounts to automatically change the password in the background. That’s all fine and dandy for the most part, ‘cept that there are caveats with the Farm Account. And low and behold, I checked and sure enough the system’s Farm account was setup now as a Managed Account in our trusty, friendly SharePoint 2010 instance.

Issue – the profile synchronization service runs as this service account. Caveat, profile sync requires that you enter the account information and credentials since you may not necessarily be sync’ing with the Active Directory resource forest that your SharePoint system leverages as its Windows Networking Infrastructure platform.

So how did we attempt to remedy this… not knowing the Farm password, it was updated in Active Directory and then using Set-SPManagedAccount with the -UseExistingPassword argument, the password was properly updated. It was then synchronized across the farm with Repair-SPManagedAccountDeployment.

So SharePoint should now be up and operational with the managed account password updated, but we also have to go and update the synchronization connection with the new password. All should be working and fine, crisis averted, just have to go in Central Admin and make the update there… But, what I thought would be a five minute fix… well, yeah, not so much.

Hello 503 error.

Oddly, after all of the troubleshooting it ended up being the bitness setting for the Application Pool that operates SharePoint was modified to operate in x86 emulation mode. This comes in handy when you need to run two different compilations of a DLL through IIS, but with our native 64 bit SharePoint application, this doesn’t work so well. Why does this happen though? Not certain but it would seem that several folks seem to have this problem when they’ve been running their SharePoint system with managed accounts automatically updating and then reverting back to an “unmanaged mode” so to speak where the metabase becomes corrupt and suddenly the fitness for x86 emulation is set to true.

More on running in both x86 and x64 mode is available here: http://blogs.msdn.com/b/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx

Please only modify this if you’re running into this problem – definitely make a backup copy before making any changes!!!

So if I want to avert this, I can force the Application Pool to start in 64bit mode by adding a “bitness64” flag… this is done in the ApplicationHost.config located in

%windir%system32inetsrvconfig

Within the Global Modules section of the ApplicationHost.config, you should search for the SharePoint14Module which should look something like this:

<add name=”SharePoint14Module” image=”C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14isapiowssvr.dll” preCondition=”appPoolName=SharePoint Central Administration v4″ />

If you want to force your App Pool to always start without x86 emulation… then you’ll want to add the following argument of “bitness64” so that you end up with something like this:

<add name=”SharePoint14Module” image=”C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14isapiowssvr.dll” preCondition=”appPoolName=SharePoint Central Administration v4,bitness64″ />

Note you’ll have to do this for each of the Web Applications that are registered – if you choose to make this modification.

And just like that… I start the application pool and all is well. Went and updated the synchronization connection and our UPS started syncing again. Qed.

More on ApplicationHost.config available here: http://learn.iis.net/page.aspx/124/introduction-to-applicationhostconfig/

SharePoint Saturday New York City – Worst Practices

What’s that? You live in New York City and you weren’t able to make it out to our session back in February at the New York City SharePoint Users Group when Scott Hoag and I presented on administrative blunders?

Well then you should definitely come and attend SharePoint Saturday New York City… and check out our session on Worst Practices. That’s right, Worst Practices – why would we waste your time telling you the best way to do things when we’ll talk about things you definitely want to steer clear of as there are so many more of them 🙂

Course the caveat is whether or not you’re able to get a ticket or get on the wait list to get a ticket. The event is being put on by a few awesome folks in the SharePoint community… so if you’re in NYC, come on out and check it out.

SharePoint Worst Practices @ SPTechCon [TEASER]

What’s that? You’re thinking about attending SPTechCon in Boston this year? You’ve got a couple days left to save a little extra money… but, irregardless of how much you save, you’ll gain great insight into some of the worst problems you can run into using the SharePoint platform… but what’s more is that you’ll learn more some of the things that you probably should do to correct poor usage of SharePoint. So if you’re around on Wednesday afternoon at SPTechCon, swing on by and check out our session.

Pitfalls of Migration @ SPTechCon [TEASER]

For those of you that have the ability to make the trek to the SharePoint Technology Conference (aka SPTechCon) later this month, you’re in for a treat for the session “Pitfalls of Migration”. Definitely something to check out if you’re looking for some tried and true knowledge along with wit and humour from two SharePoint Engineers (myself and Scott Hoag.

And if you act now, you can save yourself $500 if you register THIS WEEK (ends July 13) if you use the code USHERRegistration.

So if you’re looking for a session to attend on Tuesday morning from 830-945AM, come join us 😀 And for a quick preview…

Recycle Bin Misperceptions

I have to say that it boggles my mind on a regular basis when I start talking to end users during a session or when interviewing users in client engagements to find out that they don’t quite understand how the end user and site collection administrator recycle bins work. Most of the time I find that users have the perception that it’s a serial process where once they delete a file, they have thirty days until the file is then moved to a secondary recycle bin where a new timer kicks off – unfortunately this is wrong.

“By default, items in the Recycle Bin are deleted automatically after 30 days. Regardless of whether or not an item is sent to the users’ Recycle Bin or to the Site Collection Recycle Bin, items are deleted automatically after the number of days that the server administrator specified in Central Administration.”

As you can see, it’s plain and simple, 30 days is 30 days, no less no more.

Source: http://office.microsoft.com/en-us/sharepoint-foundation-help/manage-the-recycle-bin-of-a-site-HA010380088.aspx