I wrote yesterday about configuring AD for Office 365 and ADFS - since I had just labbed up the procedure I decided to make a video of the process and post it on youtube. Personally it was easier to record myself doing the actions and make comments as I went along AND upload it to youtube than it was to do it, take screenshots, and then compose a blog post. I hope you like it – please comment, tell me how I’m doing and let me know if you have any suggestions or anything you’d like to see covered in future videos or posts.
Author Archive for Neil Sly
Page 0 of 2
Configure Active Directory for Office 365 and ADFS
As Office 365 gains popularity and companies begin to approach truly hybrid deployments with technologies like SSO and ADFS the need to understand how it all integrates is much more important.
It’s a long standing practice for administrators to name new AD Domains with non routable suffixes (enterprise.local) or those that do not reflect their actual .com domain name bur rather the organizational hierarchy (company uses abcwidgets.com for their internet presence but abc.corp.net for their AD.) The reasons for this vary, including simplicity and a misguided effort at increased security. It’s also likely that when the AD infrastructure was originally built, 10+ years in some cases, the idea of connecting the AD to the internet was never considered. This makes sense as Active Directory has been around since Windows 2000 server (1999) whereas ADFS came with WIndows Server 2003 R2 (2005.)
As we know ADFS (and Office 365 components that leverage it) must utilize a publicly routable domain name. Thus our AD Domain for use with ADFS must not be something like .local and we must also ‘own’ the domain (not domain.corp.net as we do not own corp.net.) For many potential adopters of Office 365 this is been too high a burden to bare and has hindered. Fortunately we can use something called domain (UPN) suffixes to add our public .com to our internal AD .local and use all of the goodies ADFS and Office 365 offers us. Microsoft has a TechNet Article on the subject but as usual it’s devoid of any screenshots or further information. Fortunately it’s a very straight forward process which I’ll explain below:
Continue reading ‘Configure Active Directory for Office 365 and ADFS’
Failed to acquire the lock to object [SPWebApplication
Ran into this one tonight while re-building a webapp and doing an upgrade for a client.
Failed to acquire the lock to object [SPWebApplication Name=http://url] after 120 retries
Now I’m not one to just hit enter and try the command again whenever I encounter an error, especially during an upgrade. Usually I do some research before hand to make sure I understand the consequences of my actions. Fortunately the one point of information I found on this error was at Chris Gideon’s Blog - which recommends doing exactly that, wait a few moments and try it again. In my case I actually did an iisreset and then waited a few moments, but trying it again has worked like a charm.
SharePoint 2010 audience owner won’t resolve
This is more of an annoyance than an issue – as it does not appear to cause any problems, however I am having problems with setting the owner of an audience in SharePoint 2010. I am able to choose the owner via people picker and resolve the name fine, however once clicking save it doesn’t seem to ‘stick.’ When you view the audience properties the owner appears as a claims token, and when you go back to modify the owner it isn’t resolved (as indicated by the red line under the name.)
Note that I’ve replicated this across multiple farms – all running SharePoint 2010 SP1 w/ June 2011 CU (14.0.6105.5000) and it is persistent - I’m unsure if this is an issue with our build process, the patch level or otherwise. Note that none of the webapps on these farms are using claims – however claims is use by SharePoint by default, internally.
As you can see below once the owner has been modified it appears as a claims token.
Continue reading ‘SharePoint 2010 audience owner won’t resolve’
Run all available SharePoint 2010 Health Analyzer Checks
SharePoint 2010 has a built in Health Analyzer which runs via a series of timer jobs to analyze the health and stability of the farm. Some of the rules behind the health analyzer are a bit strict and often times you’ll find an alert for something which isn’t really an issue at all. As part of our new build procedure we always address each of these alerts before handing off the farm to the client. At issue however is that these checks run on a hourly / daily / weekly or even monthly basis. It’s a disappointment to hand over a farm only to have the client call 2 weeks later indicating an ‘error message’ has popped up in central admin. The following powershell command, Continue reading ‘Run all available SharePoint 2010 Health Analyzer Checks’