Migrating Websphere Application Server 7 BASE edition to 8.5 BASE edition issue using migration.sh - websphere

we have tested WAS 7 migration into 8.5 by using the migration.sh script and everything seemed to go fine but we have lost the graphical management of the servers and applications (not of the AdminAgent: that works fine).
Has anyone experienced something similar?
Usually prior to getting to this screen
you need to choose between
Well, as a consequence of our mistaken migration we now access directly to the above one, i.e. waspro1ANode01 (Admin Agent) but have lost the other one and all our trials to recover it have been unsuccessful.
Please, any help is most welcome !!!

Related

VB6 App on VM Runs Over RMM Utility But Crashes Over RDP

Alright StackOverflowians, this is a strange one, so bear with me and be kind. Also, this may be more of a question for ServerFault, but I'm hoping other developers out there may have seen this behavior and / or have some insight.
I have a VB6 application (custom built but the source code is long gone) which is running on a Windows Server 2012 R2 VM. When I connect to the VM using an RMM utility (ConnectWise) I can run the application as expected and everything is happy and good. However, when I connect to the VM over traditional RDP, the application crashes on startup and cites the error as COMCTL32.DLL, Exception Code: c0000005. I login as the same user in both scenarios.
I believe that this did work over RDP once-upon-a-time, but it's been probably 6 - 8 years since I've done this.
I've been finding information about the exception code listed above as an "Access Violation" and have followed some steps to disable Data Execution Prevention, but this had no effect. If I wasn't seeing this with my own eyes, I would not believe it is happening. Would welcome any tips or information, especially if you've seen similar behavior before.

Script works on Windows Server 2003 but returns error 0x8007000e on Windows Server 2012

I've a Perl script that forks in order to use Win32::OLE to extract PNGs of slides from a Powerpoint presentation. I'm in the process of migrating it from my old server (Windows Server 2003) to a new server (Windows Server 2012). The script works fine on the old server (which has Microsoft Office 2010) but on the new server (with Microsoft Office 2016), the script bombs with an error about there not being enough storage available:
Win32::OLE(0.1712) error 0x8007000e: "Not enough storage is available to complete this operation"
I've found quite a few references to this error code, but none particularly useful. Whilst this Microsoft support article says what the problem is and what to do to fix it, I have no idea why this is suddenly an issue now I'm moving to a different server and it doesn't seem to apply to my situation.
The new server has loads of spare disk space and RAM, so there should be plenty to go around. (The old server has far less of both, but that still works.)
Could this be something to do with the new server being 64-bit?
Could it be because of the differing versions of Office?
Could Apache or Perl be configured differently by default than when installed on the old server? (It's a new installation of each, but from the same source as on the old server, and I can't find any configuration that limits memory.)
One interesting point that leads me to believe that it's something to do with the script running via Apache (v2.4.27) is that if I run it from the command line (requiring a minor modification), it works fine. Apache runs as a service and I've tried running it as the same user for which it works on the command line, and that has no impact.
I've run out of places to look and things to try now, so any help would be appreciated.
UPDATE (21 August): Since nobody seems to have any ideas, I refactored my code slightly so that it gets called via a scheduled task. That works fine, supporting my theory that it's something to do with it being run via Apache. I'll keep this question open, partly in case a solution is presented and partly in case my workaround can help anyone else who has a similar problem.

How to install ColdFusion 9 in Windows 10 (IIS 10)

I'm wondering if anyone has ever figured out a way to install ColdFusion 9 in Windows 10 (IIS 10)? I understand CF 9 is not officially supported in Windows 10 / IIS 10, but I'm wondering if there is some clever way to make this work? Our ColdFusion production server is hosted by our ISP and we are unable to upgrade ColdFusion at this time, so I'm stuck with CF 9 for now. I would very much like to be able to continue to develop and test in the same version as our production server, and my new development machine is Windows 10.
I tried the CF 9 installer, chose the developer option, and got no errors until I got to the step where the installer wants to load the ColdFusion administrator page to complete the setup process where I promptly get a 404.3 not found error. I tried rebooting the machine, went to the CF admin and same results. After some further looking into this, I believe the issue was that the IIS handlers never got installed, so IIS did not know what to do with a CFM file. So even though the Admin files exist on the server, IIS doesn't know how to serve them to the browser.
When I try to use the Web Server Configuration Tool to set up IIS, it looks like it could work until I try to add all IIS websites and click OK at which point I get the error "Version 10.0 is installed. Supported versions are 4.x, 5.x, 6.x, 7.x". So might there be a way to fool the WSC Tool into thinking that IIS 10 is in fact IIS 7 or is that not going to help? I did take the step of adding the IIS 6-related management tools thinking that would allow the CF 9 installer to work with IIS 10 (this seemed to be necessary for IIS 7.x).
I have had a bit more luck running the 32-bit version of the installer, and trying to set it up with an Apache server instead of IIS, and it seemed to almost work but I am unable to create CF data sources using the ColdFusion admin, I get an error when I try to add a data source. It may have to do with some confusion about 32-bit versus 64-bit data sources, so I'll try to troubleshoot this approach some more.
Thanks in advance for any ideas/suggestions.

Oracle ODAC(with ODT) + VS2012

I installed Oracle 12 ODAC(with ODT) on two computers.
I notice two things :
The program doesn't appear in the "Windows program list" mainly used to remove/modify installed applications (only 40MB for documentation). Bad stuff, but why not...
Visual Studio is not aware about the installation and when I want to add a database connection by Tools/Connect to Database...", the new Oracle providers is not showned. VS asks for at least an Oracle 7, none is registered ! Like before to install Oracle product :(
My needs are basic, I'm quite surprise the Oracle setup has a strange behavior and doesn't seem to be fully registered.
Any idea about a missing stuff ?
Thanks by advance all,
Nd.
PS : I need a rest tonight, I'll be back tomorrow :)
I remember vaguely struggeling with the same issue. I went back to download and install the Oracle ODP.NET. That provided a setup to handle Visual studio integration and works fine for me. (Currently using ODP11.2.320)

DAO 3.6 on Windows Server 2008

For historical reasons,we have some legacy vb6 server side code running on two identical Windows 2008 server boxes that uses dao 3.6 to get to the back end MS access databases. This has worked fine for years, and we are currently in the process of migrating all the code. However, one of the servers the code is running on is getting flakey, so we need to move the code to a new server as the migrated solution will not be ready for a while.
The server that works ok is running Windwos Server Web 2008 Sp1 64 bit. The new server is Windows Server Standard 2008 R2 Standard Sp1.
In running tests on this new server, we started getting random freezing in the application. There is a simple loop that runs a select query on every table in the database.After adding a bunch of logging, it was freezing on a call to the OpenRecordset method of the DAO.Database object. Sometimes it would freeze for a few seconds, other times up to 10 - 11 minutes and then carry on. The queries being run are of this format, and should all return 0 records :
SELECT * FROM BlahBlah WHERE WriteTime > #25 Oct 2012 10:09:43#
When run directly on the database (i.e. in Access), they return fine. It's not the same query that locks up each time either. I thought that it might be something specific to our software that I hadn't managed to track down until I found a very similar post here (unfortunately with no reply except mine!)
http://www.vbforums.com/showthread.php?653166-Using-Dao-3.6-on-Windows-server-2008&highlight=dao+3.6+server+2008
The only thing I have found so far is that the version of DAO360.dll on the server that it runs on is 3.60.9704, and the version on the server with problems is 3.60.9756 (i.e. a newer version of Dao). I did not install or register anything manually, but installed Access 97 and Access 2003 on the new server, the same as the old server. I should also point out that If i move the back end code as-is to the old server, then the tests work fine, so I'm pretty sure it is not the code.
Now I know that DAO is outdated and all that, but I'm stuck with this codebase until the migrated solution is available and thoroughly tested, so any thoughts of where to look would be very welcome indeed. In the meantime, I'm going to try and manually register the 3.60.9704 version on the new server and run more tests to see if that is the issue, but it would be kind of weird if it is...
Aha ! Although we are only using DAO, not full blown access, this seems to be the answer
http://social.technet.microsoft.com/Forums/en-US/officesetupdeployprevious/thread/2a34fc07-0a1e-4248-b866-2b1c60aabba2
When I looked a bit more into it, the server that the code is running on fine is Windows 2008 webserver, which, although it is 64 bit, is a completely different beast to the OS on the new machine which is Windows Server 2008 R2. Solution seems to be to go back to an older OS on the server, rather than re-writing the whole app, which is an easy thing to do for us.
Luckily, this only has to run for another few months or so, as the whole thing is being re-written.

Resources