You would think they would have a better answer for that…

Recently I was tasked with adding some functionality to our SharePoint farms, and I started running into a very unique and troubling error.  I was trying to create a workflow using the Useful SharePoint Designer workflows solution from CodePlex.  Everything was going well, the workflow got created the way it was supposed to, but it wouldn’t run.  Instead I kept getting an error message. 

An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=”Web Application Name” Parent=SPWebService is being updated by domain account, in the SolutionManager process, on machine Machine Name.  View the tracing log for more information about the conflict.

I went to the tracing logs and didn’t find anything useful there.  So I went hunting around the internet for a solution.  Meanwhile I was also discovering that the issue was getting worse. I couldn’t delete a Web Application, I couldn’t create one, and more.  I tried any number of IISRESETs in order to resolve the issue, to no avail. In my Internet searching there were all of about 6 results for what I searched for and none of them useful. Fortunately I did find the solution.  But I also had an idea to make it easier to search for the solutions to problems when they do occur. Both after the jump.

Where do you scope your SharePoint features?

I had something occur recently that got me to thinking about SharePoint features, and where they are scoped.  For the uninitiated, you can scope features at four different locations. There are a myriad of articles out there that tell you how to make a basic feature, how to create the feature and element files, and how to associate your feature to the various components of SharePoint.  They tell you how, but I haven’t seen anything that makes any recommendations on where your feature should be scoped.

Form or Function? Which one is more important?

This is more of a philosophical post, than a technical one. 

I had an interesting question proposed by a coworker recently.  She asked me the question above.  It caught me off guard, but it got me to thinking.  Granted this was for an actual program, but it could also apply to SharePoint.  So which one is more important?  A SharePoint site may have everything that a user needs, but if it’s not laid out in a logical manner, it’s likely the users won’t use it.  A SharePoint site may be a thing of beauty, and look completely elegant, but if it doesn’t have that one most crucial element that your users need, you will likely be on the receiving end of a litany of insults from your users.

Shameless plug? You bet! (By the way I’m employed again.)

In a weird way I guess you could say that I got a sponsor for this site.  There is good and bad with this.  First we’re going to get all of the good things out of the way.

• I have a job again, that pays actual money. (Not the funny colored stuff you see in board games.)
• My job is working with SharePoint. (No I’m not going to be a janitor anywhere, although I suppose there is some sort of cleanup involved.)
• I will be able to address more SharePoint users issues than my previous experience allowed. (Now it’s not just what I discover on my own, I will use input from you, my readers, as well.)
• I will have access to better tools to test and tweak those little things that I do find so that I can answer your questions better.

Now the bad news;

• I will be working for a company that produces SharePoint features. (proprietary non disclosure agreement.)
• I will be limited in what I can and can’t say here, depending on whether the company offers a solution or not. (proprietary non disclosure agreement.)
• I can’t advocate using a competitors product. (you wouldn’t sell Pepsi if you worked for Coca-Cola would you?)
• I’m going to sell the solutions that we provide, if it is a solution to your issue.

I hope you understand, and realize that I will likely be bound by agreements, and I’m not going to do anything to jeopardize this opportunity.  It took me too long to find this work. I like the comments that I receive, good and bad, and I love little bit of traffic that I do get, but unfortunately, I won’t be able to disclose any “industry secrets.”

 

I’m not going to tell you who I’m going to be working for yet, as I still need to find out what the rules are, and what it means to my little blog here.  Keep watching for a logo to pop-up on the right though, because if I can, I’m going to put a link to it here.  With this job, I may even be on my way to being an MS-MVP. (Yeah, I laughed too, there’s no way I would be.) Just to give you a hint though, I can tell you who I’m not working for.  I’m not working for Bamboo Solutions, SharePoint Solutions, or AvePoint. As soon as I do have something substantial to post from my newfound career, I promise you will be the first to know.

So how would you rank experience?

Unfortunately I am looking for employment again.  No grudges against my last employer, but times are tough, and I understand.  In the process of interviewing for another job however, I have noticed something.  Many employers in a way to gauge how much experience I have, ask how many years I have been doing what I do.  I won’t delve into how someone can’t have 10 years of experience with MOSS, that one seems kind of obvious.  But the value of the experience you have as opposed to how long you have been doing what you do seems to me that it would probably be a better measure. How do you measure the value of experience though?

Is it too much to ask to have relative paths in InfoPath forms?

I was working on something recently to make the job in one of our departments easier.  Instead of using a word document and filling out everything manually, (which can lead to errors) I wanted to create a form using InfoPath that would allow the members of this department to select items rather than manually fill in values.  I did manage to get it working… once.  It seems that any time I recreate a site template, or even a document library using this form, I need to rebuild the data connections for the form, which means that I also have to rebuild all of the relationships in the form as well.  All because InfoPath isn’t able to use relative paths for any of it’s data sources. 

Adding printers from SharePoint

Had an interesting case come up recently.  My manager wanted a way for our users to be able to easily add our network printers to their computers.  Apparently going to \\printerserver\printer01\ is too much of a challenge for our end users.  Initially you would think that it would be simple, and that you just create a list with a hyperlink column and add the UNC path to your printer for the link and away you go.  The problem with that is, when you click on the link, somehow a magical file:/// gets added so that your link now looks like file:///\\printerserver\printer01\ which is of course useless.  An associate of mine found an article online where the solution is to create a batch file that has the link.  This of course requires a user to choose to either “save” or “run” the file.  If they can’t figure out how to get there from the UNC path given to them, chances are they aren’t going to get the batch file right either.  There is hope however, and I have figured something out that so far works for us, and will hopefully work for you too.

Do employers know the difference between SharePoint Administrators and SharePoint Developers? Is there a difference?

The job market lately has had me a little concerned for the stability of my position where I work as a SharePoint Administrator.  (I also handle other IT duties, but SharePoint is my bread and butter.)  Because of the job market, I decided that I would look and see what other opportunities were out there.  I noticed something disturbing.  Firstly, there are a lot more positions for Developers than there are for Administrators.  That’s not so disturbing in itself, but when you look at the job descriptions for each, there are striking similarities.  Go ahead and check it out for yourself.  Go to one of the top job search engines like career builder or monster, and enter in “SharePoint Administrator” for a job search and look at some of the requirements of the positions.  Now do the same thing with “SharePoint Developer.”  The thing that I have noticed is that for almost all of those positions listed, it seems that the companies have no idea what they actually need.  I think that Microsoft, or some of the more well known SharePoint genius-gurus, should lay out specifically what the difference is between an admin and a developer for the benefit of these companies so that they can ask for the appropriate qualifications for the position they are trying to fill.

Do you think Autodesk got it right this time? Yeah, me neither.

Well, I found out from our company’s CAD Support lead that Autodesk has it’s 2010 versions out now.  I figured if there was a chance that they fixed the white screen issue in Internet Explorer, maybe this was it.  I’m downloading the file now and I’m going to install it and let you know.  I’ll be back after the jump.

Tweaking "Copy List item" in SharePoint Designer workflow.

I am a huge fan of the custom workflow activities for SharePoint designer that is on codeplex.  I use an abundance of those features, all of which seem to be a shortcoming from Microsoft’s default deployment of SharePoint.  As big of a fan as I am, there are however a few things where they went completely overboard, and made it difficult for a pedestrian user like myself to figure out the ins and outs.  One of the things that I have an issue with is all of the “Copy List Item” functionality.  Microsoft came up short and the guys at codeplex went off the deep end.  Granted, I like having the ability to copy an item to another subsite, site collection, domain, or zip code by using the URL.  I’ve used it in some of my previous posts, like this one.  Sometimes though, I prefer some simpler functionality.