Hmm...This Might Work

AD User Attribute Reference

Greg Tate — Thu, 15 Mar 2012 00:47:37 GMT

I know, like the blogging world needs yet another post on AD User Attributes. There are so many out there and countless other message boards however, as I set and listen to Bill Withers sing his classic song "Lean On Me" I can't help but think maybe I should put a fresh post out for those who are new to SharePoint and new to this whole thing called AD.

I know what your thinking, why waist the energy on something this simple. I have only one answer.

Because it must be done. SharePoint loves to consume external data if given the chance.

That said for those who have stuck with me this long, here are the resources I've used in my data mapping exercises.

These are the real fun exercises you get to do when AD hasn’t been kept up and you need to pitch in to help update it so SharePoint UPS can shine through and work its magic of populating the user data from its external source. To not do this would be like leaving money on the table, after all Microsoft (MSFT) gives us Forefront Identity Manager (FIM) lite as part of SharePoint...lets use it!

Microsoft's AD Schema Page on MSDN
- All Attribute Page (Use the search feature)
Richard Muller's handy Spreedsheet of all AD Attributes

So now that we have a reference list we can use something like PowerShell to dump a list of AD into excel and begin good old fashion data massage. Of course we want to take the time to make sure this data massage is documented right? After all we can turn this documentation into our roadmap for automation to help our infrastructure counterparts an extra hand on their workload. I mean let's face it, without them we are up a creek, our beloved applications are dependent upon their work. I toast them as the unsung heroes in our professions...(just don't tell anyone)

I think this post lays the foundation for an upcoming example of "How to", which admittedly would be a greater a help than pointing you to the dictionary leaving you saying "hmmm...this might work" :)

Productivity HUB RSS Feed

Greg Tate — Thu, 16 Feb 2012 19:05:35 GMT

Recently I had the opportunity to demo the SP1 edition of Microsoft's SharePoint Productivity Hub. The environment had CISCO's ScanSafe product doing some web filtering, which was causing my claims based app to return the error of

ProtocolError occured trying to complete the request. The server returned a status code of : ProxyAuthenticationRequired and the status description is : "Proxy Authentication Denied"

After a brief period of using Google for a quick fix I discovered one of two things. Either my search was down the wrong rabbit trail or there wasn’t much in the way of useful quick fix listed for Claims Apps. Giving credit where credit is due the following site got the brain out of the fog.

From here I figured it was time to break out the MSDN site to figure out how this element works.

After reviewing the MSDN page on the defualtProxy node in the web.config, I came to the next logical step of disabling it, thinking HMMM...This Might Work

So from OLD to NEW, then a quick refresh of the browser and voila!

OLD	NEW
<system.net> <defaultProxy /> </system.net>	<system.net> <defaultProxy enabled="false" /> </system.net>

The MSDN Page Can Be Found Here.
http://msdn.microsoft.com/en-us/library/kd3cf2ex.aspx

Troubleshooting SharePoint Approval Workflow

Greg Tate — Mon, 18 Oct 2010 22:06:05 GMT

Recently I was helping someone with a troubleshooting a stock Approval Workflow within a document library. Their request was simple…”Help!” They continued with…”My workflow used to work but all of sudden has stopped notifying people until the task is overdue…not sure when this changed but I need help now.” If this sounds familiar then read on.

Since we all know SharePoint never just stops (ha ha) I figured I needed to drop down and look at the little things, never know it just might work. That said the task list was enabled to send mail upon creation and long story short I had to hit the forums for advice, after all everything seemed in order, even the little things.

The point of this post is to give props to a very helpful blog post by Steve Chen where SharePoint 2007 alerts are explained in some very good detail and another to a the creators of the SharePoint Manager on codeplex.

As it turns out the solution to the problem here was using the SharePoint manager to set the EnableToAssignEmail flag to “False”, wait for the timer job to run (after we used stsadm to verify job-immediate-alerts were set), and then using the manager tool to reset the EnableToAssignEmail flag back to “True”. One important note here is to make sure you hit save…otherwise it’s not going to write to SharePoint.

It would also be wise to remember you are using a tool that can seriously, and rather easily cause some harm to SharePoint if used by someone unfamiliar.

Not Pretty But Working

Greg Tate — Wed, 04 Aug 2010 20:16:16 GMT

I have this Farm, with two WFE’s using Windows NLB. One of the WFE’s works great, however the second WFE thinks its a great idea to throw the dreaded “Unexpected Error” message once a day for a two web apps sharing a common app pool. I think “how odd…one WFE is not in sync with the other”, so I recycle the app and all is good. As it turns out this begins to be a 24 hour pattern of a manual recycle of the app pool, obviously not acceptable.

Now…I know what you are thinking “Dude there is a memory leak somewhere, fix it”. And while I agree something is causing a memory leak I’m not sure it’s the web part everybody has in the back of their mind. After doing some research I found this forum post where it appears some others have the same problem.

I don’t have a pretty answer for this problem but I do have something that works a tad better than an scheduled IIS reset. I’ve been successful (knock on wood) in setting the recycle settings for the app pool in question to after the SharePoint search service runs.

Again…Not Pretty but seems to work so far.

A Tale of Two Database Servers – SharePoint Content DB Migration

Greg Tate — Mon, 19 Jul 2010 09:08:39 GMT

Gather round my water logged cohorts, listen to my story of pain and joy. As with most award winning novels this story starts off in similar fashion…

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Summer, it was the season of Vacation, we had everything before us, but it was virtual, we were all going direct to migrate content, we were all going to have a good weekend - in short, things were supposed to be a day in the part, that said some of its noisiest authorities insisted on much preparation and testing for the task at hand. So be it, they sign the checks, and all tested well.

The task was to move two content databases from server “A” to dissimilar server “B”. So we test, simple SharePoint backup from “A” to “B”, viola! It works, in DEV. Fast-forward to the night of…Second verse same as the first. After a few network issues around a MSFT Clustering and Juniper switch gear (don’t ask, it’s another post) fiasco we have the web apps created and content DB’s in the restore process. Oh Darn!…It didn't work we now have the following problems to address.

Q1.)Contend DB failed the restore had to manually attach content DB. Ok…

A1.)Manually attach in SQL, GUI add via Central Admin.

Q2.)The SQL Log file drive full and I didn't have admin permissions

A2.)BackUp ContentDB and Shrink Logs and give myself permissions

Q3.)Pay attention!… This is the big one! NOT ALL OF THE SUB SITES ARE ACCESIBLE. But here is the kicker. The content is visible via “Manage Content and Structure” but when I tried to drill down SharePoint said the site had been deleted.

A3.)Bring up Central Admin, Enter Define Managed Paths, and Delete the managed path to the sub site collection in question.

Now let’s try that seemly mystery site again. Viola! IT works in Production.

I hope this little story aids someone in finding their happy ending.

Oh yeah… The END.

Codecs – You know I hate ‘em

Greg Tate — Tue, 13 Jul 2010 17:07:31 GMT

As I continue my quest to make lemonade out of the proverbial lemons tossed my way during the course of a day I leave you with the following tidbit on codec's.

Since web development really isn't my strong point this many may consider this common sense but for the administrator such as myself codec's are a pain, especially when they don’t play well with Microsoft (or vice versa) and you aren't particularly an expert on them.

The problem: Streaming Application wouldn't play sound on Windows 7 machine because of missing Sipro Lab Telecom ACELP.net codec.

MSFT Solution: A workaround (use a non MSFT multimedia playback program) See MSFT Official Solution

Since The MSFT solution wouldn't cut it for me so I was left a couple of lemons, I mean options, yes options.

Hack together some JavaScript to id the browser as IE8 or IE8 Compatibility mode(native to Windows 7), set a cookie, prompt the user to self install codec and redirect to the Streaming application.
Deploy the ACELP.net codec to all the users via MSFT tools (e.g SCCM, SMS)
Re-encode the audio stream with a different codec and figure out what XML file was referencing the original audio.

Obviously choice number one sounded best since it seemed kind of convoluted, insecure, and prone to failure. But that conclusion was only made after I wrote the darn thing and realized “Dude, the browser thinks your code is malicious”

Choice number two would have worked but then my counterparts who manager those systems were in the middle of upgrading them and wanted to focus on that before anything else (go figure).

That left me with Choice number three, so out came the MSFT Expression tool which promptly converted the original audio to a windows native codec. Change of file name in the XML config file on the streaming media and all is well.

SharePoint, IE8, WebClient, And Credentials

Greg Tate — Thu, 22 Apr 2010 22:36:46 GMT

So I’ve been struggling with an odd issue here at the office. SharePoint kept prompting me for credentials in IE8 but not IE7. To fix this I simply moved the url http://sharepoint.abccompany.com from trusted sites to intranet sites. Problem Solved!…So I thought

Later we noticed when a user would attempt to open a document in any library the user would again be prompted for credentials. After what seemed like a week of Googleling (couple of hours) I discovered a two part MSFT hotfix to which I think SWEET this is fixed. But sadly the installer package informed me the fix wasn’t applicable to my machine. Seems at this point Microsoft has already included this in their service packs on Vista and Windows7. The sad thing is their service pack couldnt address the second part.

For those who havent clicked over to read the hot fix, part two added a Multi-String Value named AuthForwardServerList to your HKLM\SYSTEM\CurrentControlSet\services\WebClient\Parameters entry. Within this Key you are to define the servers to which your web client service would forward you credentials to without asking your permission(e.g *.abccompany.com).

Here is the code to get you started on Scripted fix. Just remember you will need to restart the WebClient service

Const HKEY_LOCAL_MACHINE = &H80000002

‘Set Computer Name

strComputer = "."
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

'Set Value
strKeyPath = "SYSTEM\CurrentControlSet\services\WebClient\Parameters"
strValueName = "AuthForwardServerList"
arrValue = Array("*.abccompany.com")

objRegistry.SetMultiStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, arrValue

As a parting note the HotFix states Windows XP machines aren't affected since they aren't shipped with IE8, but the ones I tested proved otherwise. Nonetheless it doesn't seem to harm the XP machines if you add this registry addition to them. Of course after this I’ve stumbled upon another issue I wasn’t aware of…a difference between user experience in IE8 32Bit and IE8 64Bit…Guess I know what I’m doing tomorrow :-)

Windows 2008 Server Logon Hang

Greg Tate — Tue, 20 Apr 2010 20:52:32 GMT

An interesting event occurred recently in a lab environment of a SharePoint Farm I was working on. This Farm (Moss 2007, Svr 2008, SQL 2008) was a medium farm scaled out in a virtual environment (VMWare)…If memory serves me we had some maintenance to perform on the VM Host which required us to shutdown all guests on this host. I figured this wasn’t a big deal since I had a fresh install of a functioning farm so I gave the VM admin the nod to take us down. Now we fast forward to the fun part…VM maintenance complete…Time to boot up the servers, up comes the SQL cluster, now the APP, then the Index, and last but not least the front ends.

As I “attempt” to log in I notice the WFE seems to be hung on the “Applying Computer Settings”…I’m not talking just a few minute hang, I’m talking an hour plus. After calling everyone in my rolodex (very short list) I had to call our pals at MSFT. Of course secretly I was hoping this was Kerberos issue since that meant I didn't have to solve it :-) (sorry Eric)

Anyway after days with MSFT their solution of course is to boot into safe mode and disable every service that isn’t already enabled in the normal startup via regedit…. I’m thinking “GREAT PLAN! Why did I call you again?"

As MSFT support was in their second day of diagnosis I noticed the following Microsoft KB article which mentioned certain essential services such as GP Client, DNS, Etc would not start automatically because of a deadlock between Service Control Manager and HTTP.SYS - This fit the observed behavior…Let’s try the fix in the KB…

Now for the fix

Boot Into SafeMode
Open Registry Editor
Navigate to HKLM\CurrentControlSet\Services\HTTP and create the following Multi-string value: DependOnService
Double click the new DependOnService value that you created
Enter CRYPTSVC in the Value Data field and click OK
Reboot Server in normal Mode

This event took three days from my life, days I can never regain so I offer this seemly simple fix yet buried solution in hopes I can save someone else.