Hi Andrew,

If you say that client #2 is not on the same domain controller, I assume he is on a different domain? I also guess the domain is trusted by the domain K2 is installed on, therefore he can browse MOSS, but how are these domains related? In otherwords is his domain a sub-domain of the domain on which K2 is, or vice versa?

Also which version of BP are you using? I know there were some mutli domain issues before, but these has been fixed in SP1.

Cheers,

Thank you very much for the reply. The plot thickens. I will explain.

It is all one domain. We have several Domain Controllers and a distributed network, but they are all just replicated DCs across a couple different subnets.

I thought maybe that was the issue since the servers and clients were all authenticating against a DC in a different subnet than their own IPs. So, I stood up a new DC in their subnet. Now - Client #1 can no longer access the K2 workspace... very strange, no? REALLY - I am not making this up I promise :)

Here are a few other observations and things I've thought about / tried:

1. I do have BP SP1 installed.
   
2. From both clients, when attempting to access the K2 Workspace it prompts for credentials (because it obviously doesn't like the client's currently logged in credentials). After three failed attempts with various domain accounts (including domainadministrator under which all K2 services were installed and actively run to include the App Pool) IE returns 401 Unauthorized.
3. From both clients, when prompted for credentials, typing in the local admin (machinenameadministrator) and password it WORKS.
4. Deploying attempts still fail because VS uses the logged in user to authenticate and reports the unauthorized error.
5. Consoled into the server, K2Workspace comes up just fine and shows domainadministrator logged in no problem.
6. I re-ran all the configuration wizards just to make sure everything was right: Server first, then Client. An odd thing here: the Server Config Wizard correctly reports the license key and type (does not expire). However, in the config wizard on the client, it reports the same License Number read from the server but it has the incorrect type and says set to expire 4 days ago. ??? Is this a bug on the client?
7. The exact error reported by IIS is: "HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration. Internet Information Services (IIS)" I'm wondering if this has something to do with the IIS Virtual directory permissions either in IIS or the file system. When I set everything up I created a new web site for the K2Workspace on port 88. Config Wizard doesn't complain about anything - and of course the workspace runs just fine locally or logged in as the local admin. But that is an IIS error. So maybe something isn't quite right? I've poked around... It's a little weird to me how K2 drops a single redirect htm file in the virtual directory that just points to the aspx files under program filesk2workspace (approximate file location). Maybe something there?
8. [Edit] Another tidbit just figured out... accessing the site by typing the IP address instead of the servername WORKS (ruling out IIS???)... hmmm... maybe a DNS issue with all the servers I was renaming and IP changing ... looking at things further. However, it did STILL prompt me for credentials, which I'm thinking it shouldn't... almost like IE thinks this server is outside the intranet even though it's just one hop over. Also: as a reminder - this issue does not affect SharePoint sites at all (which automatically authenticate just fine)... only K2 sites... and even if I can browse to it by IP address, that will still not correct the underlying problem also preventing deploying VS projects. Getting somewhere though. perhaps.
   

Anyway, I'm also seeing a kerberos error now so I'll chase down that trail too. What boggles me is that it worked on Client #1 at first and now it doesn't... grrrr.... Maybe I've done / overlooked something silly, but it does not seem like it should be this difficult to install / setup / configure and run BP on a single server.

Many thanks! 

Ok, the problem set continues to be refined:

1. 
   
2. All clients can deploy Workflow and SmartObject projects now (finally figured out that our administrator account had to be given "Export" premissions under the workflow node of the K2Workspace Management tab). A bit annoying this isn't already enabled by default on the account that installed K2. "Admin" and "Impersonate" boxes were already checked, but not "Export".
   
3. Still seeing the same thing with Browser-based K2-related operations. The problem has expanded now, however, because we've deployed a test InfoPath-integrated workflow. When we click "New Form" from the form library, fill out the fields, and click Submit we again get hit with the credential pop-up and it will not let the doamin administrator login / password through.
   
4. Again, there are no authentication problems with anything else in SharePoint or otherwise.
   
5. Putting local (machine) admin credentials into the pop-up works.
   
6. Browsing to the IP address of the K2 form library (or workspace) and putting domain administrator credentials in works.
   
7. Clicking on the K2 tab in the Central Administration site returns the dreaded MOSS "Unknown Error" page.

Anyone have any insight on the way K2 authentication is implemented and why it is not working when SharePoint is? Sorry to be a "squeaky wheel" here.

OK! Problem solved. Here are the reasons this problem was occuring:

1. 
   
2. By default IIS is set to use Kerberos authentication for web applications
   
3. There is a glaring ommission in the K2 "Getting Started" Guide that fails to mention this and states to the contrary that Kerberos configuration is unnecessary for a single server installation where SQL, MOSS, and K2 are all running on the same server.

If it was this hard to get a single server installation working, heaven help us when we go to build our production farm But I guess if others have done it so can we :)

For anyone else who runs into this in the future: it seems there are 2 options for getting around it:

1. 
   
2. Add SPNs for the service account under which the K2 web application is running. I avoided this becase:
   

• 
  
• It seemed like overkill for me just to get a simple single server prototype working
  
• Oh, and it will prevent any other web applications on that IIS box which run under different accounts from working.

• 
  
• command prompt under [default] c:inetpubadminscripts - run the following:
  
• cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"

Further documentation on these issues can be found here:
http://blogs.msdn.com/spatdsg/archive/2007/11/14/kerberos-delegation-end-to-end-part-i.aspx
http://kb.k2workflow.com/articles/kb000171.aspx
http://support.microsoft.com/?id=871179

Additional unsolicited feedback It was a bit frustrating that the K2 KBs are in a totally different site than K2 Underground. I probably would have saved a few days on this if there was a single search for both resources because that hit would have come back the first time. I'm sure there are valid business reasons for keeping them separate - and it should have occurred to me to search in both places before posting - but it didn't.

And PLEASE update the "Getting Started" Guide to include the caveat about configuring IIS correctly in a stand-alone environment. As worded now, it doesn't state that there are any special authentication considerations to make for a stand-alone deployment.

Thanks.
Andrew

Hi Andrew,

I would recommend MikeT's guide http://k2underground.com/files/folders/technical_product_documents/entry21001.aspx for when you need to work on your distributed environment.

Martin