Skip navigation
All People > SungHoon_Kim > Sung Hoon Kim's Blog > 2017 > May

I encountered this interesting behavior where the WebAgent Installer was not displaying any GUI on Windows.

The installer actually ran full installation successfully but I did not get any GUI screen.


Following is what you would normally see when you run the installer.


But this GUI would never appear.

To make matters worse, if you were to configure IIS, it is only supported via GUI configuration wizard.


The reason why this GUI did not appear was due to the setting on the OS which tells the javaw.exe not to display the GUI.



If this "Enable Java Access Bridge" is checked/selected, then it will create a file called "%USERPROFILE%\" file with following content.


InstallAnywhere actually runs javaw.exe to perform the actual installation.

This javaw.exe would read this file and not display the GUI.


If you are encountering similar behavior, it would be good to check this setting right away.


This file can be created with following command as well.


"<JRE>\bin\jabswitch.exe /enable"

This would create the same file above and result in same behavior.


However, reversing the above steps would not resolve the GUI problem.

Because as long as that file exist, the GUI would not display.


Unchecking the "Enable Java Access Bridge" option or running "jabswitch /disable" would not remove this file.

It only comments out the "screen_magnifier_present=true" line.



You must delete this "%USERPROFILE%\" file.

Then only the installer would display the GUI.

There are times when you need to import ldif export which was exported from another machine.

It is a bit complicated when dealing with ADLDS instance as there can be slight differences between LDAPs.


When you get ldif export from an ADLDS instance, you first have to perform the following.

1. Replace the {guid} value with your ADLDS instance's {guid} value.

2. Remove unnecessary lines

3. Ensure all the schema is made available in your ADLDS instance.


Let's say the ldif you received has the following.

ldif export that you received

dn: OU=netegrity,DC=sample,DC=lab
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: netegrity
distinguishedName: OU=netegrity,DC=sample,DC=lab
instanceType: 4
whenCreated: 20170202184834.0Z
whenChanged: 20170108221000.0Z
uSNCreated: 8209
uSNChanged: 8209
name: netegrity
objectGUID:: 1234567890abcdef==

dSCorePropagationData: 16010101000000.0Z


The red colour is what you need to match.

The sample has the rootDN value as "dc=sample,dc=lab" so if you are creating your new ADLDS instance, then you will have to match this.

Or, you still have option to change it on the fly during import with "-c" open when you run ldifde tool.


Then you can see the {guid} was separated in to 2 lines.

I use ultraedit or notepad++ to replace this using regex.

CN=\{.*\r\n .*\}




Then the next step is to remove unnecessary lines, those in light blue.

Same, use the regex to replace

whenCreated\: .*\n




This will remove those lines.

Repeat with other entries that are not required.


Once complete then you should be able to import it using the following command.

import ldif file
ldifde -i -f sample.ldif -s localhost:50000 -v -j C:\Users\Administrator\Desktop -a CN=admin,CN=Roles,CN=Configuration,CN={B8DA1E0A-4B22-4C07-B1F1-518811E0B02D} password -z


The sample.ldif will be imported to localhost:50000 instance.

-z option will let it continue to import even if there are errors.

ldp.err and ldp.log files will be created on the C:\Users\Administrator\Desktop

You can review the log files to see if there are any errors.