4 Replies Latest reply on May 28, 2015 11:54 AM by davidg5700

    Installation process through Workspace

    davidg5700 Specialist

      Hello all,


      We will be migrating to 9.6 SP1 in the next few weeks.  Currently we are on 9.5 using the Desktop Manager app.  We are planning to make heavier use of the Workspace app than we have the Desktop Manager.


      As the saying goes, you only have one chance to make a first impression.  When I roll out 9.6 I want to ensure that Workspace is a well oiled machine.


      In testing WS, some apps seem to take up to 30 seconds spinning while "working".  When the install starts, it will move as expected.


      Another thing I've noticed is that the refresh function does not seem to work.  I can go into Portal Manager after assigning a task to a computer, do the refresh in there, have the new app show in PM then switch back to WS to refresh and have it show there.  If I hit the >>> in WS, it generally comes back with nothing new to show.


      We have a mix of HTTP and UNC based install packages, but are moving most to HTTP.


      What I am after here is the process flow, what happens when you hit the install button... what processes kick off... what logs are written to, etc.



        • 1. Re: Installation process through Workspace
          irishmn76 SupportEmployee

          The process a software distribution package uses is the same if you're using the portal or workspaces.  The difference is that the portal app runs a policysync.exe when you open the portal app and when you click the refresh icon.  In Workspaces a policysync.exe is never ran.  The refresh icon really only looks at the local cache (Launchpad = C:\ProgramData\LANDesk\ManagementSuite\LaunchPad, and Catalog = C:\programdata\LANDesk\policies) and refreshes those links based on what is in the xml files.  Policysync.exe is the only way to get a refresh to happen and currently isn't linked into Workspaces with 9.6 SP1 and has been reported to be fixed.


          The overall architecture of the client and server interaction with workspaces looks like this (Workspaces is the Application layer that sits on the Client labled as "Application" in the diagram):

          BridgeIT client Architecture.png


          When a application is selected to be installed on the client from workspaces the normal processes happen, either vulscan.exe or sdclient.exe is called depending on the package and the download and install follows the agent settings defined for that policy.  The log files to look at are located at C:\ProgramData\LANDesk\Log

          Log Files to review:







          Hope this helps point you in the right direction. 

          1 of 1 people found this helpful
          • 2. Re: Installation process through Workspace
            davidg5700 Specialist



            This does help me along.  I have had several machines where a task in WS would spin on working and never install.  Reboots, policysync.exe, etc will not budge it even though I can install other tasks on the machine through WS. 


            The BridgeIT.log on one particular machine shows the task to have a status of 1 while the others that this log lists are either 0 or 5.  There is a CP.62.stat file referenced in the BridgeIT log in C:\ProgramData\LANDesk\Policies:











            I guess the status of 1 means something.  Is there a way to clear this out from the console and stop the task from just spinning?  Having a tasks that spins forever is not something I want to subject the end user to.


            Thanks for your help.

            • 3. Re: Installation process through Workspace

              I found that I had a CP.###.*.XML and CP.###.stat files for my spinning item in




              I deleted those with the same associated ###

              I Reopened Workspace and it now was available again and when I clicked the Install it completed properly.

              • 4. Re: Installation process through Workspace
                davidg5700 Specialist

                If anyone is interested, I found out the status codes in the .stat file at the Interchange conference:


                0 - unknown ( real useful )

                1 - working

                2 - downloading

                3 - installing

                4 - success

                5 - failed

                6 - cancelled

                7 - deferred


                dckwak: This is what I was told to do to correct the situation.  It looks like you're an LD ninja

                1 of 1 people found this helpful