Continuing with
earlier efforts to get WISP working, I attempted to re-add/re-deploy the solutions after first undeploying/removing them. Prerequisite steps:
Turn on WISP logging. You can import the following registry key to do so (save as a .reg file and double-click it; don't forget to actually create the folder):
------COPY BELOW THIS LINE-----
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\WISP]
"LogFolder"="C:\\temp\\WISP_logs"
-----COPY ABOVE THIS LINE-----
Turn on verbose MOSS (ULS) logging:Open Central Administration, click Operations.
Click Diagnostic Logging.
Under the Event Throttling section, set Verbose in "Least critical event
to report to the trace log."
Under the Trace log section, type 20 in Number of log files.
Click OK.
To add the solutions:
stsadm -o addsolution -filename CitrixWssCore.wsp
stsadm -o addsolution -filename CitrixAppDeliveryWebPart.wsp
stsadm -o addsolution -filename CitrixContentRedirection.wsp
stsadm -o addsolution -filename CitrixMossCore.wspWhile adding seems to be pretty safe, you have to be very careful about the order of deployment of the various WSPs. The CitrixWssCore.wsp must be deployed first, and this deployment doesn't necessarily work. You must carefully review stsadm output to see what your results were before proceeding. After initiating the deployment, check the
Timer Job Status page in CA to see if the job is complete and/or run
stsadm -o enumsolutions and look for the solution in the list with the
Deployed node set to true.
stsadm -o deploysolution -name CitrixWssCore.wsp -immediate -allowgacdeploymentOn this attempt, I was deploying CitrixWssCore.wsp first as directed. Note the value of the
LastOperationResult node:
<Solution Name="citrixwsscore.wsp">
<Id>fe3deba9-9b5d-4105-9983-2af1db3c0e42</Id>
<File>CitrixWssCore.wsp</File>
<Deployed>FALSE</Deployed>
<WebApplicationSpecific>FALSE</WebApplicationSpecific>
<ContainsGlobalAssembly>TRUE</ContainsGlobalAssembly>
<ContainsCodeAccessSecurityPolicy>FALSE</ContainsCodeAccessSecurityPolicy>
<LastOperationResult>DeploymentFailedFileCopy</LastOperationResult>
<LastOperationTime>4/21/2008 4:14 PM</LastOperationTime>
</Solution>
I didn't find any particular reason for this failure, but I repeated the operation, and the next time got success values in these nodes.
Once I deployed the key prerequisite package, it was on to the others. The CitrixAppDeliveryWebPart also balked:
<Solution Name="citrixappdeliverywebpart.wsp">
<Id>8a0a1be2-7648-4703-9cca-8ea0fa625793</Id>
<File>CitrixAppDeliveryWebPart.wsp</File>
<Deployed>FALSE</Deployed>
<WebApplicationSpecific>TRUE</WebApplicationSpecific>
<ContainsGlobalAssembly>FALSE</ContainsGlobalAssembly>
<ContainsCodeAccessSecurityPolicy>TRUE</ContainsCodeAccessSecurityPolicy>
<LastOperationResult>DeploymentFailedFeatureInstall</LastOperationResult>
<LastOperationTime>4/22/2008 10:34 AM</LastOperationTime>
</Solution>
This also occurred on my second attempt. So I started digging through the MOSS ULS logs (it's a good idea to turn on verbose logging before starting operations like this, as exceptions do not generally get logged to the Windows event log). I found the following key message:
Line 19554 : 04/22/2008 10:41:33.12 OWSTIMER.EXE (0x058C) 0x1404 Windows SharePoint Services Topology 8zpd High Solution Deployment : Error - Add Feature definition for citrixappdeliverywebpart.wsp Exception message - A feature with ID 94af8a34-19db-4114-876d-5a7a587a8405 has already been installed in this farm. Use the force attribute to explicitly re-install the feature.
Apparently, the uninstall procedure (I had made earlier attempts to install these solutions) did not properly remove the features. I was able to get this one to pass by adding the
-force switch to the stsadm deploy solution command.
stsadm -o deploysolution -name CitrixAppDeliveryWebPart.wsp -immediate -allowgacdeployment -allowcaspolicies -url http://server -force
After this, I forced the remaining solution deployments as well (CitrixContentRedirection.wsp and CitrixMossCore.wsp) and the rest succeeded.
stsadm -o deploysolution -name CitrixContentRedirection.wsp -immediate -allowgacdeployment -force
stsadm -o deploysolution -name CitrixMossCore.wsp -immediate -allowgacdeployment -force
After deployment of these features comes activation. Unless your application pool identity has admin privileges in various areas (this should not be the case), you will need to use the stsadm commands to activate the features. You must activate the CitrixAccessCore feature, and you must activate it before the others. Fortunately, activation does not use a timer job, so you get immediate feedback from stsadm about the success or failure of your request.
stsadm -o activatefeature -name CitrixAccessCore -url http://server
stsadm -o activatefeature -name CitrixTopNavigation -url http://server
stsadm -o activatefeature -name CitrixQuickLaunchNavigation -url http://server
stsadm -o activatefeature -name CitrixAdministrationTool -url http://server
stsadm -o activatefeature -name CitrixAppDeliveryWebPart -url http://server
stsadm -o activatefeature -name CitrixContentRedirectionModule -url http://server
stsadm -o activatefeature -name CitrixContentRedirectionMenu -url http://serverstsadm -o activatefeature -name CitrixContentRedirectionNewMenu -url http://server
The key step after getting everything installed is to configure the connection to the Citrix farm. From the site collection root, go to
Site Settings | Modify All Site Settings > Citrix Administration and specify the applicable settings. At first I tried going to the Advanced Administration and copying the contents of our Citrix farm's
WebInterface.conf file into the large textbox, but that is not sufficient.
Now if I could just get past the "No Resources found" message presented by the Citrix Application Delivery web part...
*** UPDATE ***
I got the Application Delivery web part working. It turned out the CitrixWssCore feature did not deploy properly in spite of the success message returned by stsadm -o enumsolutions. The contents of the WISP logs were the only place I saw the exception:
AccessCore.DeploymentJob: Wednesday, April 23, 2008 1:36:01 PM
Service Provider Deployment run as Identity: DOMAIN\server-farm-account
CreateEventLog() Error: Requested registry access is not allowed.
at System.ThrowHelper.ThrowSecurityException(ExceptionResource resource)
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at System.Diagnostics.EventLog.CreateEventSource(EventSourceCreationData sourceData)
at System.Diagnostics.EventLog.CreateEventSource(String source, String logName)
at Citrix.WISP.Util.CoreLog.CreateEventLog(CultureInfo locale)
....
Info: Attempting to create Web Virtual Directory (CitrixAccessPlatform-f6ec3ff1-328a-4fdf-b78b-61f0f5b703d0):
ADS Path: IIS://localhost/W3SVC/1634379371/Root/f6ec3ff1-328a-4fdf-b78b-61f0f5b703d0
File Path: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\CitrixAccessPlatform\f6ec3ff1-328a-4fdf-b78b-61f0f5b703d0
IISObject: Exception has been thrown by the target of an invocation.
Our MOSS server farm account was not a local machine administrator on the SharePoint machine, and apparently this is required for the CitrixWssCore deployment to create the custom event log and its web site. I had to grant these rights and the redeploy the solution with the
-force option to correct it. The key point is that
you must review all possible logs, including the WISP logs, to check for installation/deployment problems.Citrix, won't you please build a real installer for WISP that will take care of some of these details/checks?
