Please Log In, Please Log In, Please Log In

/TECH
Life and work has kept me busy for several weeks and is my excuse for not posting anything in quite some time. It's not much and probably not a very good excuse, but it's the one you're getting. One of the things that's been keeping me busy is that I've been doing a lot of documentation lately. Over the past 3 years I haven't documented the many InfoPath forms I've developed and am now paying the price for waiting so long. It isn't so hard as it is time consuming, not as exciting, and a lesson in how it doesn't take long to forget why you built it that way. Of course, InfoPath doesn't have any kind of documentation tool built in to it and you can't exactly add comments to your forms. So I've been using Microsoft's Word software to copy screen captures and type explanations where necessary. It's not the most amazing thing ever, but it gets the job done.

But every now and then a login box pops up and asks me to log in to the SharePoint server. It doesn't happen very often, but it's annoying because I never asked Word to connect to the server. I did a Google search and found this article outlining the same problem, though much worse than my experience with it. In the article, Ernst mentions that the issue occurs when you use a particular feature of Office to connect to a SharePoint server, but I've never used that feature directly. Somehow just by opening a document located in a SharePoint Document Library causes the issue. So I'm here to document the issue again and inform you how to remove this annoyance.

The problem stems from a feature where Office remembers the locations you've created or accessed previously and tries to connect them every now and then. To fix this, you will need to use regedit.

1. Close all Office programs to be safe.
2. Hit Win+R and type regedit
3. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Portal\Link Providers\
4. This should have one or more sub-keys with the same name as the offending sites Office keeps trying to connect to. Delete the offending keys and close regedit.

Now your Office programs should stop asking you to log in.

Until next time:
Work smart. Play well.

codeless: temporary variables

/TECH
One of the problems I ran into in January was that the userName() function in InfoPath returns something different when used on a web form in a claims-based environment. This post will walk you through two things: creating "temporary variables" in InfoPath and sanitizing the userName() result.

Temporary variables are wonderful in programming and I missed them dearly when I started working with InfoPath. Typically I'd just make a field in some obscure part of the form and not publish it, but there was always a chance that someone with some know how could find that data. It became even more prudent when I started experimenting with a service that retrieved a list of the current user's SP security groups. So I finally searched for a solution. I don't remember who's blog I read first, but there are lots of results out there that all say the same thing: use an XML file.

It's a pretty simple and clever solution. Since data connections can either be "read" OR "write", when you change the data in a secondary connection that's a read-only connection it doesn't save the data. Hey, that's kind of like a temporary variable! Constructing the XML file is pretty simple. Here's one that I've used:

<?xml version="1.0" encoding="utf-8"?>
<currentuser>
 <username />
 <preferredname />
</currentuser>

You can't specify type--as far as I can figure out--but most of the time strings are just fine. The advantage of this system is that you can get info about the current user, store it in a field for use, but not have to worry about purging the data before saving the form. This became a huge advantage with our recent userName() debacle.

In January, we launched a new web application on our SharePoint farm that utilized single sign-on and a claims-based authentication. Two major things broke when we tried using a form: accessing web services and the userName() function returned a string I'd never seen. Normally the function would return "jdoe", but in the claims-based environment it returned "i:0#.w|domain\jdoe". This was a huge issue because a lot of our forms compare the current user to some kind of list to determine access. Changing every single rule that used userName() to some unwieldy expression was not sounding fun either. So I devised a new method.

Instead, I used a temporary field and two form load rules. Using the XML example above, I then created two rules in my form load rules.

Click here to return to my listing of "codeless" blog entries. The underlined username is referring to the field in the secondary XML resource.

Rule #1 - current user has slash
Condition: contains(xdUser:get-UserName(), "\")
Action:
  Set a field's value: username = substring-after(userName(), "\")

Rule #2 - current user no slash
Condition: not(contains(xdUser:get-UserName(), "\"))
Action:
  Set a field's value: username = userName()

Now I have a field that will always contain only the username of the current user. The disadvantage of this is where you have fields that set their default value once and used the userName() function. To overcome this problem all you have to do is add a third form load rule that I like to call "First Load".

Rule #3 - First Load
Condition: FormName is blank
Action:
  Set a field's value: FormName = concat(now(), "_", username)

And that's all there is to it. Click here to return to my listing of "codeless" blog entries.

Until next time:
Work smart. Live free.

changes

/TECH RANT
I looked at my blog today and realized it has been quite some time since I last posted and there's a reason for this. Actually several reasons that all combine into a singular issue that has caused me some personal and work grief. In most cases I would mask my troubles by writing a more technically oriented entry, but this time there is no getting around the technical and emotional issues that have occurred.

To begin, in the week of January 21st we were finally publishing a form to our newly setup production environment, complete with claims-based authentication to facilitate single sign on. We did a backup of the test site collection and restored it to production. The first thing I check were the workflows as I had used a new feature to help ease the pains of changing publish locations. It worked fantastically. The workflows generated links based on where they were and didn't have to be statically set. Then we launched the all important full-trust form that was to go live by the end of January and immediately there was an error screen. Okay, so it wasn't a flawless victory. I hit OK and proceeded to attempt to visually diagnose what was broken. It didn't take long to see that every single data connection had failed to connect.

The rest of that week was spent diagnosing what had happened and what was truly broken. As it turned out, it was a small quartet of issues. The first and foremost: the test environment used classic authentication, the production environment used claims-based authentication. This small oversight caused a small cascade of issues to crop up, namely: using web services in InfoPath forms no longer worked, username() returned a very different string than expected, and SSO is really annoying to develop under.

Let's start with the string returned by username(). In InfoPath, username() normally returns something like "jdoe". And it still does when you hit preview or you happen to be using a client form. But in a web-form on a claims-based web app, username() returns something like "i:0#.w|domain\jdoe". This is a huge issue when the form is trying to compare "jdoe" to the whole claims token. This was easily enough worked around by creating a temporary variable that was assigned the current username based on a couple of form load rules. Some aspects of the form become less dynamic with this method, but it fixes the issue of "jdoe" != "i:0#.w|domain\jdoe" when it is clearly supposed to.

The next issue is that of web services. One of the services I use in most InfoPath forms is the userprofileservice.asmx service. This allows me to get the current user's preferred name, work phone number, preferred email, and Whitworth ID number. It's quite useful, and in some forms, required. And now it was completely inaccessible. At first I thought it was a problem with the string from username() causing problems, but even after I fixed that issue, the server kept spitting out a SharePoint error code 5566. I discovered this is similar to the HTTP 401 error, namely that the service is reachable, but the user has either not provided credentials or their credentials have failed to authenticate. Most sources that talk about this particular issue state that it is because InfoPath is not "claims aware", but none of their solutions work or cause a security concern.

Finally, single sign on is a wonderful tool for end users and probably even for most development situations. But for SharePoint Designer and InfoPath Designer, this caused me undue grief. This is largely due to the way the tools function in this situation. Every time I went to add a data connection, I had to log in. Every time I published, I had to log in. Every time I went to access the site collection with SharePoint Designer I had to log in, and then open the site a second time to get it to actually load. And just getting the site collection to open in the first place took me hacking the link into the Recent Sites list in SharePoint Designer. It's annoying.

At the end of this week of discovery, I found myself unable to do anything because it was all server settings I don't have access to. It was also very disheartening to realize that most of the forms I had worked on over the past 9 months wouldn't work in the production environment. My mood fell and I let a lot of things go. I probably used more sick time in January than I had previously at all. Even now I still have issues motivating myself to continue working on forms. New forms have gone to utilizing manual entry of the current user's name and ID number when needed. Where I used to have a tolerant love of SharePoint has turned into something else. I've reached the end of what little sanity I had left. When I get home from work, I can't think about design any more and usually find myself playing a game, watching a show, or reading a book that has nothing to do with work. This blog sadly refers to work quite frequently and thus it has been put off for far too long.

Don't get me wrong, I know that SharePoint can be an amazing system that provides awesome features for team sites, file sharing and collaboration, and business processes with automated workflows. I think I just need a short break from SharePoint's particular blend of crazy and a new perspective. In fact I made the decision a couple weeks ago that if I'm going to truly continue to work with SharePoint I will become an expert so that when someone comes to me and says, "It's broke", I can tell them why and what to do to fix it.

Until next time:
Work hard. Play harder.

(re)work

/TECH RANT
Remember last time when I said Doppelganger has the caveat of "subject to change"? Yeah, apparently my work projects also have that. Two weeks ago I was "finishing" a form project only to have a discussion last Monday that made me go, "Oh crap." So my main project for the past month or so has been updating our Cell Phone Allocation form to include the option of getting a phone through the company. Previously you could only get a reimbursement for using your personal phone for business related work. Now, the university is offering full-time employees phones paid for by the university and the employee takes a deduction on each pay check for using the business phone for personal purposes. What I had spaced was the fact that the addition and the deduction were opposite from each other. So in five days I re-worked a significant portion of logic in the form to properly calculate the pay period allocation or deduction.

Five days isn't much, but I managed it. The worst part is because all these changes had to be to the current form, we now need to re-convert the form for our SharePoint 2010 migration. You might think that I should just make the changes to the new form rather than re-convert but I'll tell you now, it'll be faster to re-convert. The changes were extensive and although I just finished working on it, I can't remember everything I did and really need to hand the 2010 version over to a co-worker. So re-conversion it is.

The Cell Phone Allocation form isn't the only one that's been hijacked. So has one of the SharePoint Team's least favorite form: the IRB application. This form has given us numerous problems though most of them can be attributed to user error. However, to attempt to mitigate these issues the form has been updated numerous times since it was converted. Yes, with proper documentation we could probably update the 2010 form without trouble but how often do you have good documentation available? How often do you make good documentation?

I've even been improving our documentation, but it's improvement is secondary to the immediate problems of conversion and troubleshooting. Documentation wasn't always a problem for me. In fact in programming I'm pretty good about commenting code and what-not. But SharePoint and InfoPath documentation are different because they're visual design editors with no way to comment segments. So documentation has to be put in a separate document. Which means if you update something, you have to update the documentation separately. And most of the documentation is done through screenshots of the layout and design.

I apologize to people reading this expecting to see solutions to problems on various systems. Perhaps I should move these rants to my other blog and start posting more technical things here...

Until next time:
Work hard. Play harder.

usability

/TECH
Over the summer I participated in a program here at work to journal every day and/or complete a project of some kind. At the end, the person that did the best would get a prize of some kind. But at the end of the summer when we all got together to share our summer progress, there were only six people that participated, including the organizer. Since there were so few of us, she decided that everyone would get a prize by choosing a book that she would order. She had several books laid out as options but she also said we could choose a different book of our own choosing. I requested the book Don't Make Me Think by Steve Krug, unless it was too expensive in which I'd have a different book called 62 Projects to Make with a Dead Computer. Asking if I'd mind used books--which I don't--our organizer actually obtained both books for me. So awesome.

So last Friday they turned up on my desk and I proceeded to start reading Don't Make Me Think. It's a book on web usability and the basic premise is that as a user, we shouldn't have to think about where things are, what something is, or how to use it when browsing the Web. I obtained the book on a recommendation from a friend for the purpose of personal learning. As it turns out, it has also been helping me rethink how I design our custom web forms in SharePoint. And at a very opportune moment.

For some reason a form that worked quite well last academic year is pitching a fit this semester and causing students, faculty, and staff all sorts of problems. I mean lots of problems. We have had at least 4 problems a week with user access, usage, or otherwise on a process that's had a mere 50 applications submitted thus far. And when I started reading this book we had been considering expanding the instructions further to hopefully eliminate some of the confusion. More text was exactly the wrong thing, according to Steve Krug. But redesigning the form would be even worse as it would change it mid-process for many people. So rather than putting in more text or significantly altering the appearance, I found small tweaks like just disabling buttons instead of hiding them to do instead. I don't know if it has helped yet, but here's to hoping.

Steve's book doesn't just apply to web usability though. It really applies to any GUI design whether it's web, stand-alone applications, or operating systems. I know that everything doesn't fit within the bounds of the guidelines he sets, but even he admits that everything fits nicely into it. In fact the book isn't a step-by-step guide to making particular things, but rather a set of (not-so) common sense suggestions.

I haven't even finished reading the book and I've already been able to improve so much of the designs that I think of. With the resurrection of my D&D character tracker project on the horizon, having a common sense approach to design will drastically improve the usability of the web app.

Until next time:
Work hard. Play harder.

failed to start

I would first like to apologize for my tardiness on this entry. I've been a bit busy at work and when I get home I have often been collapsing into a chair and watching old episodes of Top Gear UK. And now without further ado, my entry...

/TECH

"Failed to start"
This is an error that SharePoint workflows give sometimes. But unless you dive into some deeply buried log file, it gives you nothing else. Absolutely nothing. So we've developed a list of things to check when we receive this wonderfully informative error: check all referenced fields to make sure they're being published; confirm email addresses; make sure it gets some kind of data; clear your SharePoint Designer website cache (hate doing this); and confirm your username has been changed on that site. It was this last one for me on the most recent failure. You see, in May I went from being a student worker here to a regular employee. This meant that a lot about my account changed.

Speaking of changes and failures, another recent change caused some problems on Doppelganger. As stated last time, one of Serenity's hard drives gave up the ghost and took several of Andy's services with it. So he kindly setup backups on Doppelganger for me. I was quite grateful. The morning after the first backup ran I noticed a problem: only my Mumble server was running. Apparently I wasn't diligent enough with getting my startup scripts working properly and thus TeamSpeak and both Minecraft servers never started up properly. These have since been remedied.

I've also been trying to remedy Phoenix's performance issues. My poor personal computer is having a terrible time keeping up with the things I throw at it lately. It isn't that the hardware is going bad, or that Windows needs to be cleared, it's that my demands of performance have been increasing. One of those performance demands is actually with Minecraft. For what ever reason, the incredibly simple looking Minecraft requires a ton of resources. But the old Athlon 64 X2 with its paltry 6GB of RAM (not that paltry actually) just doesn't like running it. Then there's the games that actually justifies the need of high performance hardware.

So after having run Doppelganger on my newer, beefier hardware for a while, I've noticed something: it benefits greatly from the greater amount of RAM but not as much with the CPU. I could better utilize the CPU if I ran more process intensive servers. But the fact is I'm quite content with TeamSpeak and one Minecraft server. If I just rein it back to just the two services. I think I'll keep Proxmox, but I think consolidating services is a good idea.

It now comes down to, where do I want my hardware? I could purchase new hardware leaving Doppelganger as it is, but I'd rather purchase a tablet next. In fact in addition to wanting the tablet, I want to run a media server so that I can then stream my personal media to the device along with being able to use my various subscriptions. Having a tablet would also allow me to leave my computer and PS3 off too, thus reducing my power consumption and heat production.

Well, I'll have to consider those things while I'm on vacation and perhaps I'll have some things done in this vein by September 10.

Until next time:
Work hard. Play harder.

digging

I did a little bit on Doppelganger last week, namely setting up Warg which is running Windows Server 2008 R2. But most of my tinkering has been at work with a form and on Balrog playing more Minecraft.

/TECH
But let's talk about my tinkering at work first. I need to begin by describing a form that I'm working on migrating from SharePoint 2007 to SharePoint 2010. The form in question deals with allocating a funds to an employee for cell phones. As such, the form needs to be able to do several things right off: recognize the employee filling out the form (that's easy); query a list of current allocations and find all that pertain to said employee (hmm... okay); and check to see if the employee has submitted any forms for allocations during the current fiscal year (right).

The first part requires using the userName() function and then querying the user profile service to get their name and ID number. No problem.

The next part requires finding all the current allocations for the employee queried. All current allocations sit in a custom list which is easy enough to get to with a data connection, but how does one get just that employee's entries? Well with SharePoint and InfoPath 2010 it is now much easier to query list data connections that you receive data from. So by creating some rules that trigger on Form Load I set a field in the connection to equal the employee and then tell the form to query the connection. Boom! List of lots of allocations is now just 0 to 2 entries. This short list gives me information about each allocation along with how many allocations an employee already has. The form then presents pertinent information to set up a new allocation, update a current one, or renew an expiring one.

The last trick actually requires receiving data from the very library submitted to. This action allows us to see what other forms the employee has already submitted. But we only want to see ones submitted in the same fiscal year. Like the current allocations query, we query the forms library using the employee and also add in the fiscal year we want.

It's interesting to note that when I first modified and expanded this form that the data connection would return ALL information in the list or library and we used filters via rules and default values to get the information desired. When I looked at it this time, it just didn't make much sense to do it that way. It also helped that every one of those default values exploded in the conversion from 2007 to 2010.

Overall, I have to admit that I like SharePoint 2010 much better than SharePoint 2007. There are a few things we've had to adjust, some more annoying than others. For instance in InfoPath 2007 you could set a rule to check a condition and then do nothing except prevent any further rules from running. InfoPath 2010 doesn't allow this, but rather then just marking the rule as invalid it completely removes it without a trace. This is but a small pain though in comparison to the benefits that 2010 offers, like having a data connection sort the data returned by the field you specify. Drop-downs are now alphabetized even if the ID numbers of the queried data are out of order. The fact that data connections also have a separate set of "fields" for querying is also incredibly useful and is what inspired my recent redesign of the form mentioned above.

/EXISTENCE
As I mentioned in my intro, I haven't done much on Doppelganger recently except get one VM setup. It has really been running smoothly and I hardly have needed to mess with it since getting things set up. I guess I did move my TeamSpeak server to a new container called Raven where I now also run a Mumble (Murmur) server. But it wasn't hard and I didn't really learn much.

What I have noticed however, is that I get home from work in varying degrees of worn out--mildly to exhausted--and frequently just want to relax and not think about much. Enter Minecraft. Though it can be a very deep game with basic computer architecture simulation ability using redstone, it can also be one of the most mindless experiences out there.

It's such a strange game in that regard. it just places you near the center of 60 million square meters of blocks with a max build height of 256 meters and says, "Do something." At first you just stand there going, "WTF?" Then you move around and try punching something. You collect some dirt. If there are animals around, you might punch them a bit. Then you punch a tree and get wood. Eventually you're building a replica of Neuschwanstein castle before you come out of your stupor realizing you just spent 3 days of your life playing a game. All at once. Even forgetting to eat or sleep. (I'm exaggerating, but only a little.)

Only just today have I come up for air and realized that I need to get off my butt and get some exercise. At an embarrassing but not ungodly weight I realized that work is not going to get me moving around, rather it will keep me firmly planted in front of a computer so that I can earn strange pieces of paper-fabric which I can trade for silly and entertaining things like Minecraft, which is just more sitting in front of a computer. So today I actually went for a walk after work and managed to make it nearly a mile in 18 min. I don't know how many calories I burned, but I have a new sense of accomplishment and have set a goal down to get to 190 lbs again.

Until next time:
Work hard. Play harder.

quirks

/TECH
As most design and development is apt to have, SharePoint 2010 and its associated software has quirks. These quirks can be documented or undocumented, but they eventually come up as someone out there is trying to use SharePoint in some specific way. I use Infopath and SharePoint Designer a lot as I design and develop custom forms. One of those quirks has become apparent to me as I was struggling for several hours one day to get a workflow functioning correctly. This workflow was trying to compare a username to a person field returning the login name as a string. SharePoint 2010 is new to me and the string builder features are much improved over 2007. One of those features however broke a workflow. It turns out that the new string builder treats the '\' just like most programming languages: it's an escape character. Thus when I had it trying to concatenate a '\' in a string, the lookup following it kept failing as it was no longer being a lookup but a string literal. Again, as with programming using 2 '\' actually inserts the character into the string.

/EXISTENCE
Speaking of escapes, currently I've gone through another bout of gaming remorse, this time from Diablo 3. I spent an unhealthy amount of time on the game over the last weekend, thus not getting useful things done, like working on my projects this blog is supposedly helping me follow through with, finishing my re-organization project, getting a haircut, doing laundry, or going grocery shopping. Was it worth it? The frustration and self-defeating said "No, and you're a loser for wasting all that time".

But I know I'm not a loser. It takes me a little bit of time to get over the initial depression that sets in, but then it turns into a priority defining moment for me. It was because of those thoughts and the realization that I can actually do something about those problems that in the time between writing the previous paragraph and this one, I went and got my hair cut and grocery shopping. It's amazing at how much better I felt after something as simple as getting my hair cut.

The same thing goes for work. Last week by Friday I was burned out. I was just wasting the University's money by sitting there while I did nothing but stare blankly at my screen. So I left early. Today I went to work and before I knew it, it was time to leave. In fact I stayed a little longer today because I needed to finish something before I left. Perhaps there's hope for me yet on accomplishing 40 hours per week.

Until next time:
Work hard. Play harder.

back to work

/TECH
Doppelgänger still doesn't have a power supply, but I've been waiting until I got back to work before I began spending money on the project. The PSU is just the beginning for the system. For the time being, I'm going to use my old AMD Athlon 64 x2 hardware. I've only got 2GB of DDR RAM for it currently, but I hope to replace all the core hardware before the end of the year. The hardware I'm looking at putting into the case is an AMD A-series CPU+GPU, an accompanying FM1 motherboard, and at least 16GB of DDR3 RAM. I'd prefer 32GB, but we'll see what I can afford throughout the year.

On that note, as of yesterday I'm once again employed and continuing work for Whitworth University. It's a great place. Of course I have some complaints about the work and the area, but those issues are far less significant than being able to say, "I'm employed, eating well, enjoying my evenings in the house I live in, and sleeping comfortably." But this is tech talk, so let me elaborate on the issues I'm currently dealing with at work.

As a brief intro, I work with Microsoft SharePoint creating custom forms with InfoPath. Our current project is migrating from SP 2007 to SP 2010, which is one of the issues I'll discuss. The other issue is providing support for existing forms with both InfoPath 2007 and 2010 installed on my workstation.

If you've ever had to upgrade even a personal computer, you know that migrating data from the old version to the new version doesn't always go smoothly. I love advertising that states it's simple and seamless. Bollocks. It's only simple if all the conditions are right and when is a server ever perfectly stable and up to date with the latest hotfixes? I've been developing custom forms for our SP2007 environment for the past two years and although I don't have to re-learn everything, I have to become acquainted with the quirks of each environment and the quirks that come with the conversion process. On top of this only some of our forms are actually being converted to 2010; some are remaining in the 2007 format but being published to the 2010 environment.

One of the InfoPath 2010 quirks is that you cannot specify a rule in a form that only stops the remaining rules from running. Every rule must have at least one action and stopping the remaining rules doesn't count. To mitigate this you simply have the rule edit a dummy field with nothing. Problem fixed, right? Well, the conversion quirk that comes with this is that when InfoPath 2010 imports the 2007 form it takes a look at the rules and any of those "stop" rules are removed. No warning. No making the rule invalid. Just remove the rule without notification. Microsoft, that was a stupid idea. This breaks a lot of the functionality in the forms I develop. I rely on that rule to stop the other rules from running and causing errors. And I don't even have to be converting. Even if I'm just publishing a 2007 form to the 2010 environment as is those "stop" rules disappear.

But we're going about this smart and we haven't pushed the 2010 environment into production yet. This means that we're running both 2007 and 2010 environments. As a result I have both 2007 and 2010 versions of InfoPath and SharePoint Designer on my workstation. However, because a key change to the contact selectors happened with InfoPath 2010 the two versions of InfoPath are incompatible. So when 2010 is the primary application I have to be cautious about editing 2007 forms with IP2007. The reason is that if there's a contact selector in the 2007 form I can't edit the control at all. So when I have to do maintenance on a 2007 form I have to repair the 2007 installation which takes time and requires the computer to be restarted. Then the next time I open 2010 it updates the computer again breaking contact selectors in 2007. It's a constant battle.

/EXISTENCE
Of course I talk about all this and remember that I have plenty of distractions awaiting me at home. These come in the form of a large Steam game library, a PS3, and my newest addiction: Minecraft. I'm a bit late to the Minecraft scene but Oh! how grateful I was late to the party. The game is so ridiculously addicting I'm sure I would have done much worse in classes had I purchased it earlier. In the course of 5 days I've probably sunk 50+ hours into it. I'm really happy I bought it during my vacation so that I could spend that initial period with it. And then there's my backlog of games I have yet to complete or even start! Hell, I even went as far as using a website to help me track that backlog, speaking of which I need to update.

Until next time:
Work hard. Play harder.