Hi Kurro,
if the production stores data that needs to be maintained in the DB, you need to do something more complex (like mapping the data globals in the new NS to the old DB.

If not the safest way to test and also migrate everything is what you are proposing:

• make a backup of the original DB (freeze/thaw or the iris utility from management portal, restore to different location and keep an eye on NOT SETTING SWITCH 10 during restore https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls... online backup)
• create a new NS copying from the old one
• do the mapping accordingly
• import the upgraded code in the new NS
• disable all the producion pieces (BO / BP / BS) on the new production
• disable the production part (brands) that needs to be migrated on the old version
• enable them on the new version

If something on the new production goes bad, you can easily enable the disabled pieces on the old version, and disable them on the new one.

Pietro

Hi,
may be that you are connecting to the webserver port and not the superserver one?

Can you post an "iris list"?

You can also include the connection in a try/catch and check on iris in application error logs and audit database (the audit db probably is the one that you need to check first).

you can have a look at a script that i've made that basically implements a remote cli to iris

https://github.com/m0nt0/riris/blob/main/src/riris

no no for the testldap don't remove it. Test ldap will run the query as it will do on the login giving you the output of the search for debugging. May be how samacountname is written?

On an AD installation i got it as "sAMAccountName"...

never tried but worked with a lot of copy between versions and architectures (think that this isn't different).

The first error is from the restore, you are trying to restore a db on an existing one with different block size (8k vs 16k may be). Try to restore to a new database and this will be solved.

The other problem that you are facingis that replacing the mgr will result in a broken instance.
With the restore and also by copying the databases (more or less is the same thing), I would NEVER restore the default databases :

IRISSYS
IRISLIB
IRISLOCALDATA <-- probably could be replaced
IRISAUDIT <-- probably could be replaced
ENSLIB
HSCUSTOM
HSLIB
HSSYS

I'd say that if you can shut down both instances you can simply copy the iris.dat files in place from windows to container. This way you won't lose time in doing backup / restore

Keep in mind that every configuration done needs to be synced on the container (users, privileges, web applications, roles, namespaces,....).

Hi,
you could configure sudo like

irisusr ALL = NOPASSWD: /usr/bin/systemctl stop httpd.service

where irisusr is the user that runs iris.

For the other server you could do the same thing and setup ssh to authenticate via keys

On source server:
su - irisusr
ssh-copy-id this_is_the_other_web_server


but the real question is: why do you want to stop httpd?

You could configure webgateway to have the other server as a failover.

configure connection to server2
setup application to be server1 primary, server2 backup

unfortunately unless you got a very very high log set in the instance and a very long journal history you can't discover that.

If you got the info you can find in the journal the global change, get the process info and search the log for them. But usually is something that you can spot in the near time or something that happens on a regular basis, something spot is really difficult to find in that way.

Hi,

never done that, always installed production under linux. Respecting the allocation size it will be good to match the same size so if you are using only 8k, it should be better to have 8k also on fs so 1 unit for db should also be 1 unit for fs and it won't be split in 2 fs operation. 8k should be fine because you can accept that if you are using a mixed db allocation size for 8k and 16k it will always be beneficial also for 16k chunks.

On this argument always remember to align the partition and the fs dropping the first bytes as per ms best practice so that also the disk (if on a raid) could match the writes

https://support.microsoft.com/en-us/topic/recommendations-and-guidelines...

Hi,
the error is quite generic and it basically says that you can't login but you don't know why.

Check that the superserver port is the same used in studio,

Check the license on the instance.

If the everything is fine, fire up the management portal, go to
system administration -> security -> auditing -> enable auditing
and check that the auditing is enabled. After that go to
system administration -> security -> auditing ->  configure system events
and check that
%System/%Login/LoginFailure
is enabled. If not click on "change status".

Try to login again with studio and check the audit database
system administration -> security -> auditing -> view audit database
and see what error comes up

Pietro