A
** Unused **
I think our listener is broken, it keeps reporting back "TNS:listener does not currently know of the service requested in connect descriptor."
What should we do?
First, double check that the listener service is running at all. If so we might need to rebuild it:
-- stop service
-- delete service
-- net manager, delete old listener
-- add new listener
-- configure with default and SID
-- lsnrctl start
... But if this reports back connection to an idle instance, then we have some more digging to do.
** Unused **
A customer is trying to upgrade from version 2014 to 2025. They have all the appropriate files, but just need to know which scripts to run and in which order. And are there any special considerations regarding the actual DD.exe?
They will need to run:
-- updt_2014_15.3.sql
-- pre-16.sql
-- update_2015_to_2021x.sql
all from the original 2014 DD.
Beyond that they will still need to run:
-- v2_conv_prep.sql
-- update_to_2024.sql
-- update_to_2025.sql
from the current 2025 DD.
** Unused **
What are some of the common causes for "Waiting for DBCA to Start" during o19c.exe install?
1) File paths containing illegal characters (such as spaces)
2) File paths that are too long
3) 7zip4powershell not extracting
4) Smartpage blocks on any part of the oracle package
5) Requesting too much memory for SGA+PGA
A user remotes into their TEST server and sees all their settings set as expected (pink background, correct data, etc...). But then disconnects from their rds and then connects back into the same connection from their local client, but the TEST instance does not look the same (brown background, incorrect data, etc...).
From both the Help > About screen as well as the IQStatus > Connections we see consistent values of both. The same SID, HOST and PORT. They look to be an exact match.
What is likely issue.
The two separate workstations (the local and the remote) exist in different states and connect to separate servers with the exact same name.
By dis-ambiguating the Hostname as an exact IP address, we can get these two connections to actually match.
During Oracle 19 install, I get a recurring and unexpected error:
Failed to add VBT\VBT install user to %2% group
We have done all of the "common" troubleshooting for filepaths/directory/unblocks/memory, but continue to get this error. What might it indicate?
I have only seen this in one environment and is due to naming the windows user the exact same value as the hostname. In this case both the Host and the User are "VBT" and this will fail.
Using any other account should bypass this error.
During Ataman setup, we "seem" to have gone through setup as expected. We started the atrls service, created a new iqrf.bat file, created new ataman user and added our prompts.
In follow-up testing, IQRF.exe runs as expected. We can run the iqrf.bat directly. But when trying to telnet localhost, the screen just stays black for a time before reporting timeout.
Assuming all of the prompts/passwords are filled as outlined in the Ataman technote, one possibility is the bat file naming and extension.
Specifically, if the computer is set to "hide extensions" but the file shows as iqrf.bat, it is possible/likely that the real name is iqrf.bat.bat.
How can we ensure that a TEST email sent from system parameters > email is using the values shown on this page? What other values might it be looking at?
Changing the EPlant to "view all" mode.
Otherwise, the TEST EMAIL function will test with the applicable enterprise > eplant > contacts.
The silent installer is failing to setup an oracle client. You check their Client/oracle folder and find only a pair of instant clients (like 19_14 and 19_19). How would you manually install these and finish the EIQ client install?
1) Copy the instantclient folders into C:\oracle\client
2) Take a copy of a working Network folder from another workstation (or manually write the TNSNames.ora)
3) Add the instantclients to Environmental Variables > System > PATH
4) copy and run the registries for SOFTWARE\WOW6432Node\ORACLE and SOFTWARE\ORACLE (exported from another workstation or even our own laptops)...
At which point, you should hope to be able to run Silent.exe without issue... otherwise, run Client/enterpriseIQ/setup.exe
** Unused **
We are just finishing an upgrade, and have submitted our log for review. But we are getting a pair of unresolved dependencies:
SMP_BLOB and SMP_LONG_TEXT
What should we do about these.
They are old and outdated tables, no longer applicable to our current system. It is safe to just drop them:
Drop table SMP_BLOB
/
Drop table SMP_LONG_TEXT
/
Then you can re-run resolve dependencies, and it should clear.
I am going to change my window's IQMS-Service account password. This is the window's admin user that runs Oracle, Ataman and IIS. Is there anywhere I need to change this password besides microsoft?
Oracle: "none" unless services have been tied to the service and password is updated manually
Ataman: In the atrls control panel > Prompts > Password.
IIS: In the identity fields of apppools associated with the user (and good to double check that sites still are accessing the pages, else password might be saved in "authentication" and lower level site user settings).
When running the JavaMail Utility from the install media, I get an error "Unrecognized or badly formed option -" and it fails.
Why might I see this error?
Extra context, here is the list of arguments: -user sys/***@iqora -v -r -grant PUBLIC -synonym C:\Users\lwsadmin\desktop\delmiaworks 2024 - Refresh 5\Utilities\JavaMail\Javax.mail.jar
Like the Oracle installer, this utility will break with special characters in the file path. They had taken the bulk of the install media and put it in a custom directory on the desktop.
** Unused **
From all indicators, we should have successfully installed Shopworks appropriately, but when trying to access the website, it remains blank and doesn't even show a login prompt. BUT, we have even logged into Shopworks successfully from another computer.
What should we look at?
First, check your browser. Both IE and Firefox have given us trouble with Shopworks in the past, and this sounds like a bug (from reports, this may only be an issue in 2024+).
Beyond this, probably best to try incognito mode or remove all cache/cookies.
When my user tries to access IIS websites, I get "THOTH GATEWAY ERROR"
What is going on?
Typically this error is cleared by Grant iqwebdirect_role or through security inspector "green checkmark" grant webdirect access.
Sometimes you need to go one step further to grant connect.
We have run through all of Setup.WebIIS, added identity user to both Shopworks and LicenseService apppools. Now when we run the Setup.LicenseImporter it shows good non-expired values and appropriate seats, and when you click import, it reports back "successful".
But after all this, we still get "unable to contact license service" message when logging into Shopworks. Where should I look next?
The two most likely causes are C:/IQMS/WebIIS/Shopworks/appsettings.json or Data Dictionary > Tables > Common_Services_Tracking.
Even after running the setup executables, these can save old/incorrect locations.
Everytime you open EnterpriseIQ, you are prompted to update your localhome to match your masterhome, and after IQStatus > Apply, you only get one updated file. And the next time you try to open EnterpriseIQ you get the same error message.
What is a likely cause?
This can be caused by Windows Smart Screen (or potentially other AV). After updating and trying to reopen the file, the AV has to edit the date modified, and the file keeps being "out of date" with the masterhome.
In these cases, you would want to check the masterhome files for "unblock" options.
All of a sudden, this morning, we have users in the system, but most of our users are now getting "authentication errors" when trying to access IQWin32. Through DD > Users logged in, we can verify that we are well below the limit.
We just reset out IQMS password, and some users were able to log in, but many of our users are still getting the same "password mismatch" as before.
Why does it keep locking up on us?
The IQMS user was reset, but other users as well as some automated applications (like IQAlert) are holding on to the old password, and very quickly creating a string of failed login attempts.
This can be verified in DD > Audit log (return code 1< x < 27999).
This is why we say that the system has to be locked down or even restarted after IQMS user update. But as a temporary work around, we can update the IQMS user password AND the default password policy to allow for extra failed attempts.