Skip to main content

We have hundreds of desktops running wIntegrate version 6.4.4.  After migrating to RHEL we want to find an easy method to enable SSO for all our desktops with wIntegrate.  

We would like to run an automated script (using powershell or something) to update all our desktops so we don’t have to update each desktop individually, but the manual states that you cannot edit the session .wic files with a text editor because the files are in a binary format… that you need to use the wIntegrate Editor to edit the .wic files.  This doesn’t sound like something that can be easily automated.

We have experimented with using a text editor (Notepad++) to update a .wic file before, and wIntegrate seems to properly recognize the changed setting... so it seems feasible that an automated powershell script could find and update all .wic files with a new setting. 

Has anybody else had success updating settings in a wIntegrate .wic session file without using the wIntegrate editor to compile the .wic file?

We specifically want to set GSSAPIAuthentication=1 in the .wic file.

Thanks in advance.

We have hundreds of desktops running wIntegrate version 6.4.4.  After migrating to RHEL we want to find an easy method to enable SSO for all our desktops with wIntegrate.  

We would like to run an automated script (using powershell or something) to update all our desktops so we don’t have to update each desktop individually, but the manual states that you cannot edit the session .wic files with a text editor because the files are in a binary format… that you need to use the wIntegrate Editor to edit the .wic files.  This doesn’t sound like something that can be easily automated.

We have experimented with using a text editor (Notepad++) to update a .wic file before, and wIntegrate seems to properly recognize the changed setting... so it seems feasible that an automated powershell script could find and update all .wic files with a new setting. 

Has anybody else had success updating settings in a wIntegrate .wic session file without using the wIntegrate editor to compile the .wic file?

We specifically want to set GSSAPIAuthentication=1 in the .wic file.

Thanks in advance.

Hi Daniel,

Your summary above is correct. (The format of the .WIC files was chosen as this was a Microsoft standard at the time.)

Here's what to do:

1. Start a session on your own PC. Use the dialogs to change the required settings to support SSO. Save the session as, say MySession.wis. (You can save it as either a .WIC or a .WIS file. The latter are easier to read and edit.)

2. Edit the newly-created MySession.wis session script. You can see that all the session parameters are set as variables in this script. Find the variables which have changed to support SSO. You will copy these updated lines and paste them in later.

3. On your PC, find the script ...<username>wIntegratewIntSysIconBarar_gen.wis. Every user has this script. It is executed every time the application starts and lets you customize what icons ther user sees. You can see it referenced in the saved file MySession.wis where it is assigned to the variable CommandBar_2.

4. Edit the bar_gen.wis script and paste in the updated lines copied from the MySession.wis file.

5. Copy the new bar_gen.wis script to the users' machines overwriting the existing file in ...<username>wIntegratewIntSysIconBar. You can use PowerShell to do this.

6. The setting will be applied the next time the user starts the session.

7. The new setting won't be saved unless the user clicks the Save button, but it will be set again by bar_gen.wis every time the user starts the program.

8. I can't remember if the program prompts you to save the session if you have unsaved changes. If it does, that would be messy. A better way to do it would be to call a new script Set_SSO.wis from bar_gen.wis. The Set_SSO.wis script would
 * set the required session variables
 * save the session
 * revert the bar_gen.wis script back to its original form so the new variables aren't set every startup. /
 * / or set a flag somewhere that PowerShell can read later and revert everything back.

Anyway that's the theory! I'm sure it's all doable but I can't try it as I no longer have the program installed.

Best regards,
David