Sweserijnen. nl

Category: AppV

  • Fixing WinZip MSI error when sequencing with AppV 5.x

    In AppV 5.x I have been sequencing applications pointing the primary virtual application directory (PVAD) to a dummy folder like C:\apps. The primary virtual application directory is the location where the virtual file system (VFS) will be created during sequencing. The reason for using a dummy folder is the inability of AppV connection groups to merge only the VFS when it comes to files. I want to be prepared to use the application in an AppV connection group if necessary.

    When sequencing WinZip 17.5 in AppV 5.0 SP2 beta in this way the following error appears when starting the application:

     WinZip_error

    The solution seems to be very easy to implement. The error “Unable to install over the MSI version of the installation. Please obtain the MSI version or uninstall WinZip first” will not appear when the PVAD points to the initial installation folder of WinZip and Winzip is actually installed to the initial installation folder. Setting your PVAD to C:\Program Files\WinZip and actually installing to C:\Program Files\WinZip will solve this error.

  • Unexpected behaviour when upgrading AppV 5.0 SP1 sequences

    One of my students noticed some unexpected behaviour when upgrading an AppV 5.0 sequence for the second time. I haven’t run into this unexpected behaviour earlier because normally I make a new sequence every single time.

    In AppV 4.x the standard behaviour was to append the internal version number associated with the sequence to the .sft output file. The .osd files would then point to the new xxxxx_2.sft file and so on and so on. In AppV 5.0 SP1 this is only true the first time:

    first_upgrade

     

     

     

     

     

    When a sequence is upgraded a second time the internal version number is appended to the already added internal version number from the first upgrade:

    second_upgrade

     

     

     

     

     

    With a third upgrade the unexpected behaviour is even more clear:

    third_upgrade

     

     

     

     

     

    I haven’t come across anyone else mentioning the same behaviour, but I would imagine that I am not the only one that has noticed this unexpected (not standard) behaviour.

  • Removing all AppV 5.0 sequences at once

    In AppV 5.0 I couldn’t find an alternative to the SFTMIME REMOVE obj:app /global /complete command I used so much in Softgrid\AppV 4.x. Not even searching for it in my favorite search engine Google. Until just now when I stumbled on the following possibility while trying different PowerShell combinations on the AppV Client.

    Keep in mind that you can’t remove sequences that are part of a connection group. So you have to remove connection groups first. Use the command:

    Get-AppvClientConnectionGroup -All | Remove-AppvClientConnectionGroup

    After removing all the connection groups it is time to remove all the sequences. Use the command:

    Get-AppvClientPackage -All | Remove-AppvClientPackage

    The only thing I haven’t figured out yet is how to remove all the empty folders that are left in C:\Programdata\AppV\ with PowerShell. And the client doesn’t seem to handle this forceful removal very well seeing that connection groups aren’t automatically republished. Work in progress…

     

  • Impromptu 7.4 User Version won’t start from within Beaufort 3.3

    INTRO

    The company I work for as an external consultant consists of four individual companies merged into a new company and thus a new environment (new forest, new domain, etc etc). Every individual company carries out it’s own application migration. Two of the individual companies each use the Beaufort application and wanted to consolidate the Beaufort application (Human Resource application). As a first action their two separate Beaufort databases were merged into one of the existing databases and the merged database was placed in the new environment. It is important to know that one of the individual companies is already migrated to the new environment and the second individual company is in the process of migrating.

    In the new environment different drive letters are assigned for locations that hold either consolidated applications or non-consolidated applications and drive letters are divided to hold either the application or the application data. In the existing sequence the Beaufort application (RAET\BEAUFORT 33 and Cognos folders) was installed to K:\Beaufort and the application data (CUO, Impromptu and INTRACOM folders) was installed to M:\Beaufort. These are the locations for non-consolidated applications of the already migrated individual company. The Beaufort application worked as intended.

    Seeing that the Beaufort application needed to be consolidated I made the decision to make a new sequence instead of upgrading the existing sequence because the installation locations needed to change. I made a new sequence based on the installation manual for the existing sequence and changed the installation folders to R:\Beaufort and S:\Beaufort.  These are the locations for consolidated applications. Without this new sequence the already migrated individual company had no valid way of  reaching the merged database in the new environment.

    During functional testing we came across the problem that Impromptu couldn’t be started from within the Beaufort application. The Beaufort application has a menu structure with the option to start Impromptu. The Load catalog screen was shown but after that an error was generated on screen stating that the S:\Applicatie_data\Beaufort\EZ3.3\Impromptu\Catalogus\SE_orad.CAT catalog could not be opened. SE_orad.CAT is the default security catalog installed during the initial installation.

    TROUBLESHOOTING

    I started an command prompt within the virtual application with the command-line:

    SFTTRAY.EXE /EXE cmd.exe “<Full Application package Name>”

    Full Application Package Name is the combination of SOFTPKG NAME and SOFTPKG VERSION. After browsing to the right folder I started ImpUser.exe and Impromptu started without a problem.

    After that I started the Cognos_Impromptu.osd which I kept in the sequence and Impromptu started without a problem.

    By then I began focusing on the Beaufort database to see if it contained misconfigurations. I was looking for paths pointing to network locations of the second individual company. I started investigating Cer5.ini and IMPROMPTU.ini for misconfigurations.

    All to no avail.

    SOLUTION

    Just that day the DBA responsible for the database migration sat at the desk across from me. We started to troubleshoot together and found the problem and how to fix it. I must say that without the DBA I probably would never have found the cause of the problem.

    He started asking me about the contents on the TNSNAMES.ORA so I showed him. Entry for the merged Beaufort database was as follows:

    BO2PP.WORLD =
    (DESCRIPTION =
    (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)
    (HOST = <ORACLE-SERVER_1>)(PORT = 1522))
    (ADDRESS = (PROTOCOL = TCP)
    (HOST = <ORACLE-SERVER_2>)(PORT = 1522))
    )
    (CONNECT_DATA =
    (SERVICE_NAME = bo2pHA)
    )
    )

    This is the way how a High Available solution (Data Guard) would normally look for an Oracle database. Instead of one server name and port number 1521 a second server name is added en the port numbers are changed to 1522. I’m intentionally forgetting all the backend configuration needed for this configuration in this blog because it is out of the scope of this article.

    The DBA then informed me that the entry needed to be changed because the application Beaufort can handle a different port number but the application Impromptu can’t handle a different port number. Apparently he ran into the same problem a few weeks earlier at the second individual company.

    We changed the entry as follows:

    bo2pp.world =
    (DESCRIPTION =
    (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)
    (HOST = <ORACLE-SERVER_1>)(PORT = 1521))
    )
    (CONNECT_DATA =
    (SERVICE_NAME = bo2pp)
    )
    )

    After that we tested Impromptu from within the Beaufort application and Impromptu started and worked as intended.  Rest assured that this solution is now documented within the company (and this blog) and a warning is issued to all application owners to check all other applications if they can operate when a Data Guard solution is active.

  • Changing the AppV content store location and how it affects sequences already published in RES Workspace Manager 2011

    Let me start at the beginning….

    Way back in June of 2012 I came to the project I am about to finish. During the start of the project the AppV content share was placed somewhere on the DFS. We were told (repeatedly) that that location was never going to change. Based on that we made about fifty sequences with the UNC location of the content share on the DFS as the location were the sequences reside. In conjunction with file based streaming this solution looked solid. The sequences were published in RES Workspace Manager 2011 so all the osd files were imported in to the RES Workspace Manager database.

    In hindsight we should have implemented an environment variable from the start, but for reasons unknown we didn’t.

    Just recently I was told that the location of the AppV content share needed to change. It was placed on a location that was prone to filling up with excessive data. I had a meeting with the system administrators to name some of the actions that needed to be executed.

    Defined actions:

    • Create a new LUN dedicated to the AppV content share.
    • Copy all sequences from the current AppV content share to the new AppV content share.
    • Edit the Preload scripts.
    • Edit all osd files on the new AppV content share and replace the UNC path with an environment variable.
    • Edit all sequences that are published through RES Workspace Manager and replace the UNC path with an environment variable.

    The first two actions (LUN and copy) were completed by the system administrators. Actions three and four were completed by another member of the migration team and me. I edited the Preload scripts (modified versions of the Wilco van Bragt preload scripts which can be found here). Another member of the migration team wrote a PowerShell script to change all the osd files on the new content store.

    PowerShell Script:

    $osds = Get-ChildItem -include *.osd -recurse -path \\[path to new AppV content share] foreach ($osd in $osds)
    {
    $osdFile = $osd.fullname
    $xml = New-Object XML
    $xml.Load($osdFile)
    $xml.SOFTPKG.IMPLEMENTATION.CODEBASE.HREF = $xml.SOFTPKG.IMPLEMENTATION.CODEBASE.HREF.ToUpper().Replace([path to new AppV content share], “%SequenceStore%”)
    $xml.Save($osdFile)
    }

    And for the last action I had to consult RES Software. I opened I case with the question if there is a bulk method of changing the osd files in the RES Workspace Manager database. Within a few hours I received a response which proved good enough to implement.

    The key combination CTRL + SHIFT + F9 opens up the screen below IF you press them in the Administration – Custom resources node. According to the mail of RES Software. In the dutch interface I found it at Configuratie – Datastore – Maatwerkbestanden.

    RES_CTRL-SHIFT-F9

    After selecting Microsoft App-V Integration and clicking OK I am presented with the following view.

    RES_App-V_Integration

    This view makes it easy to rapidly change all the osd files that are present in the database without having to open each individual published application to discover if it is in fact a published AppV sequence and to change the osd file by clicking in the “Click here to change the OSD file in the datastore” line in each published sequence. Which in the end saves time.

    This option made the transition to a new AppV content store a lot easier to implement and it sped up the implementation a lot. Any improvements on the PowerShell script and RES Workspace Manager bulk edit action are more then welcome in the Comments field.