none
Runtime and Full access install on Terminal Server

    Question

  • Hi Experts.

    Several users are currently running Access2003 on a Windows Server running Terminal Services.

    We want to upgrade the users to Access2010 without the big expense of multiple licenses, so intent to install the Access Runtime for the users.

    The catch is we also need a full version of Access 2010 for Development.

    Can anyone please advise if:

    1/. Is it possible to install both the Full and Runtime on the same machine?

    2/. Is it possible to install the Runtime to selected users and the Full version to other users?

    3/. The best way to achieve the above (if possible)

    Thanks...

    Monday, April 18, 2011 11:36 PM

Answers

  • Actually, the way this works is that if you attempt to install the runtime, it notices that the full edition is installed, and thus does nothing.

     

    In effect you can install the runtime, but it does nothing. In fact, if you could install the runtime it would in fact over write the full edition of Access. Keep in mind that ONCE ANY part of office installed for a given version then any and all additional parts of the officer suite (Excel, word etc) MUST and WILL follow into the same directory. In other words, once one part of office venison xx is installed, then ALL ADDITIONAL parts follow into that install dir. The reason for this is of course that MANY parts of the office suite are shared (spell checker, VBA ide editor, ribbon code, the list is quite long).

     

    What this means is that once you installed one part of office, the two things occur:

     

    All additional installs go to the same dir (due to shared parts) and you NOT be given a choice to change or switch the install directory.

     

    The runtime must install to the same location as the full edition, and thus it does not install else you would be blowing out the full edition.

     

    In a nutshell, this means you can install the runtime, but it will not really install. For users to launch Access in runtime mode you will simply have to provide a correct short cut with the /runtime switch, or rename the database to an accdr extension.

     

    So, while you cannot install both at the same time, you can in effect simply run Access as runtime mode for uses and run it in full edition mode for development.

     

    There also likely the issue that you do need to install the runtime so the TS licensing system knows this, else you be restricted in the number of copies you can run at a given time. So, while installing runtime does noting, it does create a entry in the install/uninstall list and I suspect the TS licensing server will need this info to allow multiple copies of Access to be used without additional CAL's being purchased for office.

     

     

    Albert D. Kallal  (Access MVP)

    Edmonton, Alberta Canada

    Tuesday, April 19, 2011 6:54 AM

All replies

  • Hi there,

     

    I think most of your questions will be answered to read info at http://www.hitechcoach.com/.

    Mostly reffering to 2007, but certainly applicable to 2010 in most of the cases.

    http://www.hitechcoach.com/index.php?option=com_content&view=article&id=14:acess-2007-runtime-deployment&catid=7&Itemid=9

     

    Also this link is very useful and recommended to read;

    http://msdn.microsoft.com/en-us/library/cc136539.aspx

     

    HTH,

    Daniel

    Tuesday, April 19, 2011 2:15 AM
  • Hi Daniel,

    Thanks for the links but they do not seem to address Terminal Server issues or cover a dual installation, although I now am thinking this is not possible due to shared registry and shared components.

    I would appreciate it if someone can confirm this or provide a method to allow runtime for all while still having the full package for development?

    Thanks.

    Tuesday, April 19, 2011 3:51 AM
  • Hi there,

    I am not 100% sure how they did it, as Tech Guys installed this for me.

    I had developed Runtime Apps in Access and let them distribute via Terminal Server.

    I had both, the Full Time access and Runtime on my PC. They can run together.

     

    Daniel

    Tuesday, April 19, 2011 4:34 AM
  • I'm not entirely certain Full Access 2003 can work with Terminal Server and even 2010.

    Here's Tony Toews web site on TS.

    http://www.granite.ab.ca/access/terminalserver.htm

    Scroll down...

    Tuesday, April 19, 2011 5:36 AM
  • Actually, the way this works is that if you attempt to install the runtime, it notices that the full edition is installed, and thus does nothing.

     

    In effect you can install the runtime, but it does nothing. In fact, if you could install the runtime it would in fact over write the full edition of Access. Keep in mind that ONCE ANY part of office installed for a given version then any and all additional parts of the officer suite (Excel, word etc) MUST and WILL follow into the same directory. In other words, once one part of office venison xx is installed, then ALL ADDITIONAL parts follow into that install dir. The reason for this is of course that MANY parts of the office suite are shared (spell checker, VBA ide editor, ribbon code, the list is quite long).

     

    What this means is that once you installed one part of office, the two things occur:

     

    All additional installs go to the same dir (due to shared parts) and you NOT be given a choice to change or switch the install directory.

     

    The runtime must install to the same location as the full edition, and thus it does not install else you would be blowing out the full edition.

     

    In a nutshell, this means you can install the runtime, but it will not really install. For users to launch Access in runtime mode you will simply have to provide a correct short cut with the /runtime switch, or rename the database to an accdr extension.

     

    So, while you cannot install both at the same time, you can in effect simply run Access as runtime mode for uses and run it in full edition mode for development.

     

    There also likely the issue that you do need to install the runtime so the TS licensing system knows this, else you be restricted in the number of copies you can run at a given time. So, while installing runtime does noting, it does create a entry in the install/uninstall list and I suspect the TS licensing server will need this info to allow multiple copies of Access to be used without additional CAL's being purchased for office.

     

     

    Albert D. Kallal  (Access MVP)

    Edmonton, Alberta Canada

    Tuesday, April 19, 2011 6:54 AM
  • Hi Albert,

    Thank you for your knowledge.

    Further research shows that the Full retail pack of Access 2010 will not install on to Terminal Server. I need to purchase a Licensed / multi user CAL licence.

    I will try your suggestion to trick the licensing system to allow runtime and full access.

    Thanks to everyone for your ideas.

    Monday, April 25, 2011 8:45 PM
  • I created a new thread here with a similar topic yesterday, and some "helpful" person from MSFT moved it to the office forum where I would say it's unlikely to get any input. I would like to tag my question on to the end of this 2011 thread, which luckily has not been moved off of the Access Dev forum.

    What's different about my situation is that I do have two msaccess.exe for 2010 installed on the machine, because I used the cmd line install technique for the runtime install. However when I run the runtime, it acts exactly like the retail Access. The body of my yesterday's post is below.

    There is a lot of good content in this older thread. What would work fine for me would be to install the regular version of Access 2010 on the server, and to run all of the user instances of the db using the runtime switch, and for myself to debug etc use the retial. I gather there is a special license needed for office installs on windows 2012; is it ok to run it in the kind of mixed mode I've described (one retail user, else runtime)?

    >>>>>>>

    On a server that will publish an Access 2010 desktop app via RDS (terminal services), I have installed both retail Access 2010 and runtime Access 2010. I planned on using the retail Access for debugging and some mild development on the server, while all users would use the runtime via the shortcut which would explicitly start the accdb with the runtime msaccess.exe. However I find that no matter what exe I point the shortcut too, the retail version of Access starts.

    I used the command line installation technique to install the runtime into a special dir, so that the two installations would not be combined.

    The two shortcut paths are like this:

    "C:\access2010rt\Office14\msaccess.exe" "C:\myapp\northwind.mdb"

    "C:\Program Files\Microsoft Office\Office\msaccess.exe" "C:\myapp\northwind.mdb"

    Even if I start the exe in the runtime folder, if I go to Help it shows Office 2010 Pro Plus.

    But regardless of which shortcut is used, retail is used to run the app. How can I force the server to use the runtime of Access?

    Revision: when I start the accdb using either of the shortcuts, and inspect task manager, I see that the msaccess.exe that is running IS the version that the shortcut points to. But it always 'looks' like retail Access?

    Friday, September 6, 2013 10:05 PM
  • Your basic problem is still much of what I outlined above.  Office is a SHARED system. So the VBA editor, the ribbon, the spell checker and 1000's of other bits and pieces ONLY get installed once. 

    If you install word 2007, and then word 2010

    In VBA we then go:

    myWordApp   = createobject("word.application")

    What version of word will Access create?

    Answer?
    The last one with all the current REGISTERED 1000's of bits and parts that is SHARED.

    I was not aware that you could force the runtime (msaccess.exe) to install to a different location (did that really work???).

    However assuming you managed to do this, you still have the problem when the office program attempts to use VBA, the ribbon, the report designer and as noted 1000's other bits and parts.

    Those bits and parts are "registered" and consumed by your program (they use a process VERY similar to create object internal). Hence it makes not a lot of difference that you launching msaccess.exe, but then consuming the 1000's parts that been installed + registered. So all of the report writer and other parts are still full retail (there are HUGE parts of Access that are not part of msaccess.exe). This likly suggests there is NO difference between msaccess.exe for full vs runtime, but it all those other parts I speak of.

    It matters little what .exe program I launch and it THEN creates a instance of installed word. The launching of the .exe file does not change what word is registered and active.

    Bottom line:

    You cannot have two sets of installed components of the same version of ONE program installed. There no way to distinguish between those registered parts.

    This ALSO explains why you cannot install 32 and 64 bit parts of office on the same computer (same release version). The reason again is because such parts attempt internal to do things like create object(current ribbon)  or use VBA.

    The nature of this shared system and problem is simple these parts are all shared. The runtime does not overwrite and re-register all the full retail bits and parts. The result is your only going to get + use the retail edition you installed.  If the runtime could install and re-register everything  then it would hi-jack all of the full retail parts. The result would be a non-working full edition of Access.

    You simply cannot have two versions of word or Excel or in our case Access of the SAME version installed on the same machine (that shared bits and parts is the problem).

    This also explains why you get that long "switching" and re-installing like dialog when you switch from say Access 2003 to 2010. (the bits and parts for 2010 are being re-register so when parts like the VBA or spell checker or ribbon are requested to the consuming program then the correct part is returned and dished out by the operating system).

    If office was not a shared "com object" system and all those bits and parts registered were not shared, then this could work.

    If you going to deploy + use runtime on your terminal server then I not aware of a way to have both editions installed.

    The SageKey installer might allow this (check with them). However the standard install + registering of the bits and parts required to run an office program suggests you not get around this issue.

    Another possible solution would application virtualization(as opposed to OS virtualization).

    One workable suggesting would be to develop with full retail Access 2010, but install the 2013 runtime for users. Thus only you would use 2010, and all other users would use 2013 runtime. This would remove the stepping on each install issue as per above.

    The other would be to simply not install 2010 full edition on the TS, and have 2010 full on your local development machine.

    Best regards,

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada


    Monday, September 9, 2013 12:11 AM
  • Albert your input is appreciated. Yes, it possible to dictate the install location of the Access runtime. I do have two Office14 stacks, the runtime one lacks word.exe and so forth. Both msaccess.exe are identical, and both execute as Access, but all of the registry stuff refers to the retail stack. Thinking it through re how office objects are instantiated, I can see that it's not a fine grained enough system to point to a specific instance of an app (I/we wish), so there has to be one Access, one Word, etc, as far as com goes.

    I had no idea that the Access report write was not part of msaccess.exe, that's a major surprise.

    I've seen you mention application virtualization before, and I had a little exposure to that topic around five years ago, but I think that company is either out of business or acquired, and I lost track of them. Do you have any specific product to recommend for this purpose?

    It is a neat notion to use the Access 2013 runtime and 2010 retail. But wouldn't there still be contention for which version is "Access" to the registry, whenever a version is started that is different from the last version started? Sans a sagekey-type solution.

    Does anyone know if it's ok in terms of licensing to install Access 2010 retail on the ts server, and run the app for users using the runtime switch or accdr? They won't have Access to any other Office products on the ts box. I thought that option might have been mentioned earlier in this thread.

    I really want to be able to run the app on the ts box using retail Access, mostly for purposes of debugging.

    Monday, September 9, 2013 2:56 AM
  • >>I had no idea that the Access report write was not part of msaccess.exe, that's a major surprise.

    Well, perhaps I should say "parts" of the report writer are external (pdf creating, ribbon etc.). So some parts likely are inside of msaccess, the "unknown" issue would be how much is outside via those external shared bits and parts I spoke of.

    >But wouldn't there still be contention for which version is "Access" to the registry, whenever a version is started that is different from the last version started?

    Yes – that configuration issue would likely still exist. This would still be much like trying to run two versions of Access at the same time. Even right now launching 2003 and then 2010 is a VERY bad idea to have both run at once. However, it would be worth a try – if users have separate profiles then some additional isolation "may" allow this setup to work. You could test this.

    >Using runtime switch and ignore licensing.

    I very much doubt this is possible. I not 100% sure, but my spider sense says doing so will not make one bit of difference to the licensing server that runs in this case.  For example, keep in mind that you cannot automate the Access runtime from other applications using createobject(). You can however shell out to msaccess.exe and use getobject(). 

    What would happen to code that does a createobject("access.application")? Such code again would need full version of Access. I just don't believe the licensing system is able to distinguish this case. Since we don't have fine enough control over the registered bits and parts – those parts are going to be seen as retail version and the licensing server going to see things that way also.

    I just think having full access on your local computer is best. However if you have all kinds of folders + sql server etc. that typically make up a given company, then you need a dev version on that "network".   As noted I think in this case you just have to install + setup ms-access on some other server on that network. Often when an organization has terminal services, they often have a few other servers running. You could place full retail Access on that server. Or even have a single computer that you remote desktop into.

    The cost + time expenditure to cook up some working solution of running both versions on the same box is going to cost more than just setting up Access on some other box to be run remote.

    Best regards,

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Monday, September 9, 2013 4:37 AM
  • My sow bug sense tells me you're right - probably the way to go is runtime on ts and retail on another server. I will just have to live with the fact that I can't debug the app under the identical conditions which the users experience.
    Monday, September 9, 2013 1:23 PM
  • Hi Rusticloud,

    I resolved the original issue by: install Runtime to the server for licensing purposes. ( add as many users as needed.)

    Then install the full version (multi-user CAL licence) with just one licensed user.

    The net result as albert details, is every user actually uses the Full version, but as they are all running the application using an .ACCDR they are effectively using Runtime so have no additional license issues.

    As developer I can make changes to the application (accdb) then save as an ACCDR to each users appData folder for regular runtime usage.


    Brian, ProcessIT- Hawke's Bay, New Zealand

    Friday, October 4, 2013 12:56 AM