[Windows 7 Ultimate 32-bit Original Key 94fbr
Jamar Lizarraga
My misfortune is that I purchased the update from 4 to 7 from NI when it first came out, but due to a series of family crisis was not able to get back into the studio and install it. My PC's are not recent but I do have Windows 10 and Cubase 8.5 running well in 32 bit.
There has been much catching up to do and I really cannot abandon all my 32 bit projects that require 32 bit VST's. It was my hope that I could get to use Komplete 7 until I learned that Service Center is gone. After installing Native Access I was able to register the package and several of the programs are listed as able to download or locate on my system.
First, I downloaded Kontakt 7 and saw that no libraries were found. So I installed the libraries from my DVD's. They are not recognized by 7 but can be accessed in 4. Next I downloaded the Vienna Concert Grand, which is recognized it 7 but are seen as "demo" in 4.
I am not sure about the order here. I might have installed Kontakt 4 first but could not activate it. I could be that when I downloaded 7 that it automatically activated 4. I am pleased in any event that I can use the original orchestral samples, but am confused as to what is happening. Has anyone else had this issue or something similar?
Right after I posted this, I was checking versions of FM8 on Native Access as I had just downloaded the most recent 32 bit version. Then when I loaded FM8 to see the version it was "magically" registered with my license number. Then I loaded Guitar Rig 4 and it was registered also. I still get "demo version" when I try Vintage Organs and Vienna Concert Grand, but there does not seem to be any limitations to use them.
It's worth noting that (and my apologies if you know this already) 32-bit/64-bit mainly has to do with how much RAM can be utilized by your device. 32-bit has a hard limit of 4GB RAM (which is not much for today's standards), whereas 64-bit has practically none. Also, 32-bit apps can run fine under a 64-bit OS, but not the other way around.
Following up for anyone who is interested. The key for me was installing the latest 32 bit version of Kontakt. As I mentioned earlier I have many projects that depend on other 32 bit plugins for now. After installing Kontakt 6 Native Access registered everything I have installed so far. Battery 3, Guitar Rig 4, Abbey Road Drums, Vienna concert Grand, FM8, Vintage Organs.
These still show as demos in Kontakt 4, but there I can use the default, built samples that were installed with it from my DVD's. Many features in Komplete 7 are not that useful to me but I will probably install them while I still can.
Since Cubase 32 bit and 64 are said to be able to co-exist, I might go ahead and install the 64 bit version and update to the available 64 bit NI plugins that I can. I hesitated because this pc is originally a Windows 7 pc that has only an i7 2.9ghtz dual core processor, which runs good for now.
If you install from DVD, or generally instalation files, you must run Native Access after that to authorise instalations. If you install it using download by NA, it will be authorised automatically after installation.
After reading through several forums, I learned that some 32 bit plugins did not work well in 64 bit versions of Cubase. Since all the plugins I have been using in older Cubase versions were 32 bit and my software package Komplete 7 was definitely 32 bit, and my pc is older, I attempted to work with 32 bit Cubase 8.5. 8.5 was said to the most backward compatible, but I did not know if that included the 64 bit version.
My original concern was that NI announced on its site that legacy software was not supported by Native Access. The whole issue is more confusing that it needs to be IMO. Gladly I have been able to activate everything that I have installed so far except one item that Native Access shows as available. Akoustic Piano, which I have licensed from Komplete 4 is listed as available but will not load. It is on one other pc, but the official statement is that two are allowed.
The fact that some, not all Komplete 7 items are listed after entering my serial number in Native Access led me to believe that the more important ones were not available. It was only after installing Kontakt 6 32 bit that I was able to activate the plugins installed from my dvds.
I started writing up this question, but I found what I think is the solution in attempting to document the steps to my original failure. Can someone please let me know if I have this correct? Skip to the bottom if you want to see my solution, because in between here and there are all the steps I was testing--with increasing degrees of success--as the solution (I hope) dawned on me by degrees.
We just moved from MAS90 4 on one server (with workstation clients) to MAS90 4.5 on another server, with all clients now running the new MAS90 via RDP on the terminal server where it is installed. A couple of them now need to access the new MAS90 via ODBC (MS Query in Excel and/or MS Access). We do not want workstation access to MAS90 applications--just the ODBC driver. This is because we do not want phantom copies of old MAS90 workstation installations hanging around after future MAS90 upgrades.
Do you wan the Sage ERP MAS90 registry entries to be deleted? This will cause ODBC connections (such as, Crystal Reports or Visual Postmaster) for all Sage MAS 90 or 200 installations on this computer to fail.
This seems to infer that answering "No" will leave the MAS90 ODBC DSNs. I answered "No" and proceeded to complete the un-installation. I then successfully tested the MAS90 DSN and, sure enough, it worked--until I rebooted. Although the MAS90 driver appears on the list of drivers, any attempt to configure the existing MAS90 DSN or add a new one after the reboot is met with this message:
On the theory that pvxodbc.dll was missing from System32, I reinstalled MAS90, captured a copy of the DLL, un-installed MAS90, and went to re-copy the DLL--but there was already a copy in System32. I could have saved some time by just looking to see if it stayed there in the first place, but either way, it was to no avail, as I received the same message as above:
The module "C:\Windows]System32\pvxodbc.dll" failed to load. Make sur ethe binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found.
That sounded awfully familar--very much like all the prior failure messages, but I noticed the reference to possible dependent DLL files, so I reinstalled MAS90 and was rewarded to find, with a bit of guesswork based on file name and date, the accompanying pvxio.dll file. I then un-installed MAS90. This DLL behaved slightly differently from the other one in that, while it remained in place in System32 until reboot, it disappeared upon reboot.
This predictably broke my DSN again, but adding it back to the registry again fixed the DSN. Then there was just one more step, based on a hunch--the deletion of the license information under this registry key (with the live informaiton replaced with dummy data, since the live data is our actual serial number):
Once again, testing revealed that the DSN required this information at runtime (popped up a dialog box asking for license information). Adding it back to the registry gave me what I think is a fully-functional DSN without a prior workstation installation on the computer. It all comes down to this now:
Now, this was 32-bit Windows 7, and I know there would be some adjustments for 64-bit Windows 7 and even perhaps for XP, but those can wait. Of course, I also had to enter the DSN configuration information (paths, etc) from a known good configuration to make a usable DSN.
I successfully added these two DLL files and the registry entries to the one computer still having a MAS90 client (to our old version, on another server, for reference purposes), first ensuring there were no naming conflicts over overlaps in registry/file names, and I was then successfully able to add a new DSN which can successfully connect to the new MAS90.
Did I miss anything, or was there (as likely as not) a simple ODBC installation routine hiding somewhere in the MAS90 folders on the server--or, worse yet, another post in this forum that explains all of this?
I do have one question, however. One of the pressing reasons for me to figure this out, but which I did not include in my post, was that the company CFO needs to retain access to the old server via his existing v4.0 workstation because it contains several old companies which they did not want to migrate to v4.5 on the new (terminal) server at this point (maybe later). It will not be in conflict with v4.5 on the terminal server, but how would I go about installing 4.5 on his workstation, as you suggest, so he can get just the ODBC driver (which is all he needs of v4.5 on his workstation)? Would that not conflict with the existing 4.0?
It comes down to this: he needs both his existing 4.0 workstation as well as the 4.5 ODBC driver on his workstation. Maybe it is a faulty assumption on my part that there would be a conflict if I were to install 4.5 on the same workstation.
Being not a MAS90 specialist, but a systems administrator responsible for the broader picture of ensuring the overall health and orderliness of both servers and workstations, I have often found two things when users remove a program folder manually without a proper uninstallation of the application:
795a8134c1