One of the AgilePoint Integration for SharePoint features is that, the process is cancelled once the document is moved to target library.
In some cases, the users may want to keep the process running even the document is moved to another library. The solution for this is to associate the same process template at the target library.
Here is the issue:
Environment:
a) Two AgilePoint Servers in VMWare ESX virtual environment.
b) Cisco NLB device for network load balance
c) Two SharePoints on physical machine in NLB
Symptom:
AgilePoint task list web part on SharePoint works or not work sometime.
- Error message from web part: Unable to connect AgilePoint Server. Verify the Impersonator credentials in AgilePoint Configuration List
- Check AgilePoint SharePoint log file, it HTTP 401, Unauthorized
Steps to solve the issue:
STEP1:
a) Run TestWSConn.exe (AgilePoint test tool for cluster) and connects local AgilePoint Server – worked fine
b) Run TestWSConn.exe on SharePoint machine and connects one of remote AgilePoint Servers directly (no cluster name/IP) – HTTP 401, Unauthorized
c) Run setspn.exe, TestWSConn.exe worked from remote machine
STEP2
a) Run TestWSConn.exe on SharePoint machine A and connects AgilePoint Server using cluster name/IP -- worked fine
b) Run TestWSConn.exe on SharePoint machine B and connects AgilePoint Server using cluster name/IP -- HTTP 401, Unauthorized
c) Reset IIS of AgilePoint Servers. It worked on SharePoint B, but not on SharePoint A.
d) Switch non-sticky mode to sticky mode on Cisco NLB device. Both A and B worked fine.
Challenge from customer in this case:
Usually, the team we worked with does not have permission to configure the machine, device and Windows. So they are reluctantly to bother administrator of network, domain, virtual environment. They would try to prove the issue is caused by AgilePoint product. Here is the challenge:
a) They show you the cluster name/IP works on IE by browsing AgilePoint Server web service --- means web service works fine
Answer: browsing web service wsdl does not go through authentication, so it does not prove the authentication is fine.
b) They show EnterpriseManager works fine --- means configuration is OK
Answer: EntepriseManager is form authentication and connect to local AgilePoint Server. It does not prove authentication from remote machine is OK
c) They tell you the administrator has set principle name by running setspn.exe
Answer: deploy a generic test.asmx to two web appl one with LocalSystem and other one with AgilePoint Server AppPool (service account)
If one with LocalSystem works, but does not work AgilePoint Server AppPool. That proves principle name is not set correctly.
*Notice, LocalSystem does not need principle name
*test.asmx is a simple file with simple and generic web service of Hello()
d) They say the testing environment work fine in VMWare virtual environment --- meaning virtual environment does not have problem
Answer: In this case, the SharePoint and AgilePoint are on one single machine. It is local connection. Run TestWSConn.exe from workstation machine and connects to testing AgilePoint Server, not working. That proves VMWare environment has same problem.
Strategy for troubleshooting,
In general, NLB troubleshooting is hard because it could be hidden root cause or multiple cause. In this case, it was VMWare network driver, setspn and Cisco NLB configuration. Setting expectation at beginning is very important:
a) Troubleshooting may take long time. In this case, it took a week from beginning to end, total hour is 7 hours. Because the team needs to get help from other team. That takes days some time.
b) We are not expert of database DBA, not hardware engineer, not domain/network administrator and Cisco NLB expert. What we can do is to narrow down the problem and provide useful information and direction to customer.
Any proof in generic way would be easier to convince customer that is not AgilePoint issue. For example, deploy a generic and simple web service to prove principle name is not configured correctly. Customer would understand immediately and they are willing to get other team’s help.
I have a client that run into this issue. In Windows 7, my client is not able to connect to AgilePoint Server from Envision. But there is no problem to connect to AgilePoint Server from a Windows XP machine using Envision. In this case, disabling UAC in the Windows 7 machine solves the issue.
Here is how to disable the UAC.
Run cmd “msconfig” and you will see following window. Select ‘Change UAC Setting’, then click on the Launch button.
In order to disable UAC, make sure the slider control is at the bottom as shown below.
Also check Event Viewer Permission and make sure current logged on user is administrator has has full control on Event Viewer.
When designing a List Form AgilePoint process, it is common that you will add on more fields along the way building the process model. Here is how you add more fields after the List Form process template is created.
Go to File > SharePoint … > Retrieve Meta Data Schema.
Then select the fields available. You can also specified if you want the field to be editable, read only or hidden on your list form UI.
A client of mine tried to configure a remote Exchange Server in AgilePoint Server Configuration windows (see picture below), but it always failed to connect when clicking on the Test button.
In this case, for SMTP server you have to put the IP address or FQDN, not the OWA http url.
SharePoint Integration v1 MSI installer does not deploy ListForms Integration. This is because ListForms Integration is introduced after the distribution of SharePoint Integration v1 MSI has been stopped. User has a choice to install the ListForms manually using the stsadm command line tool.
But, if somehow you manually deploy the ListForms wsp to SharePoint and the deployment is not complete, then the upgrade installer is not able to upgrade for you.
For example, in this test environment, the ListForms wsp is found in the SharePoint solution store, but the it is not deployed (check this using enumsolutions command, and look for the <Deployed> element for ListForm, i.e. <Deployed>FALSE</Deployed>, see picture below).
If you run the upgrade installer, it gives you below errors in the upgrade log.
Default location of the upgrade log is YourDrive:\Program Files\AgilePoint\Upgrade\xxxxx[PickTheLatest]xxxxx\upgrade.log
4/13/2011 12:15:38 PM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -immediate -allowgacdeployment
4/13/2011 12:15:40 PM>>SharePoint Integration v1: Error, Solution "ascentn.sharepoint.listform.wsp" is not deployed. To upgrade the solution in the configuration database, omit the -time, -immediate, and -local flags. To then deploy to the front end, use the deploysolution command.
4/13/2011 12:15:40 PM>>SharePoint Integration v1: Information, Adding solution Ascentn.SharePoint.ListForm.wsp to the SharePoint ...
4/13/2011 12:15:56 PM>>SharePoint Integration v1: Error, A solution with the same name "ascentn.sharepoint.listform.wsp" or id "1f0a6833-6b4a-417b-9d6b-52d0fbbf21dd" already exists in the solution store.
C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp: The Solution installation failed.
To solve this, simply manually clean up the ListForms wsp from SharePoint by running deletesolution, and then run enumsolutions to make sure the ListForms wsp is not in the solution store anymore.
stsadm -o deletesolution -name Ascentn.SharePoint.ListForm.wsp
stsadm -o enumsolutions
After that, run the upgrade installer again.
The upgrade installer will try to upgrade the solution first. If the upgrade is unsuccessful, which means there is no existing ListForms solution, then it will add the ListForms solutions. See log below.
4/13/2011 2:08:19 PM>>SharePoint Integration v1: Information, Upgrading solution Ascentn.SharePoint.ListForm.wsp in SharePoint ...
4/13/2011 2:08:19 PM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -immediate -allowgacdeployment
4/13/2011 2:08:24 PM>>SharePoint Integration v1: Information, "Ascentn.SharePoint.ListForm.wsp" does not exist in the solution store.
4/13/2011 2:08:24 PM>>SharePoint Integration v1: Information, Adding solution Ascentn.SharePoint.ListForm.wsp to the SharePoint ...
4/13/2011 2:08:38 PM>>SharePoint Integration v1: Information,
Operation completed successfully.
4/13/2011 2:08:38 PM>>Copying application bin content...
4/13/2011 2:09:12 PM>>Application bin content copied successfully
4/13/2011 2:09:24 PM>>SharePoint Integration v1: Information,
Executing .
Operation completed successfully.
4/13/2011 2:09:24 PM>>execadmsvcjobs, bSuccess = True
4/13/2011 2:09:24 PM>>Updating SharePoint Integration v1 ... finished
The details of deploying the ListForms manually is available in the v5.0 Installation Guide, page 10, 2.1.1.3 Additional Manual Upgrade Steps, 2.1.1.3.1 SharePoint ListForm.
Updated 04/14/2011
Changes made to the upgrade installer: the installer will try to upgrade using –immediate switch first, if it fails, that means the listform wsp is added to the solutions store, but user has not run the required manual step to deploy the listform wsp to desired sites. Refer to Installation Guide to for the manual steps.
4/14/2011 10:42:38 AM>>SharePoint Integration v1: Information, Upgrading solution Ascentn.SharePoint.ListForm.wsp in SharePoint ...
4/14/2011 10:42:38 AM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -immediate -allowgacdeployment
4/14/2011 10:42:40 AM>>SharePoint Integration v1: Information, Solution "ascentn.sharepoint.listform.wsp" is not deployed. To upgrade the solution in the configuration database, omit the -time, -immediate, and -local flags. To then deploy to the front end, use the deploysolution command.
4/14/2011 10:42:40 AM>>Omitting -immediate switch...
4/14/2011 10:42:40 AM>>SharePoint Integration v1: Information, Upgrading solution Ascentn.SharePoint.ListForm.wsp in SharePoint ...
4/14/2011 10:42:40 AM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -allowgacdeployment
4/14/2011 10:42:49 AM>>SharePoint Integration v1: Information, Solution "ascentn.sharepoint.listform.wsp" is not deployed. It is upgraded in the configuration database. To deploy to the front end machines, use the Deploy method.
4/14/2011 10:42:49 AM>>Ascentn.SharePoint.ListForm.wsp is added to the solution store, but not deployed. Refer to the Installation Guide for manual steps to deploy Ascentn.SharePoint.ListForm.wsp.
4/14/2011 10:42:49 AM>>Copying application bin content...
4/14/2011 10:43:06 AM>>Application bin content copied successfully
4/14/2011 10:43:15 AM>>SharePoint Integration v1: Information,
Executing .
Operation completed successfully.
4/14/2011 10:43:15 AM>>execadmsvcjobs, bSuccess = True
4/14/2011 10:43:15 AM>>Updating SharePoint Integration v1 ... finished
