TIP: Getting Queue Manager 11.1 working on remote machines

  • Hi, as you can read on the forum, after updating Poser Pro to 11.1 any remote workstations with QM will stop working as they are still are of an older build number like 11.08xyz... And apparently the Poser- and QM build numbers need to be exactly the same, otherwise they won't work together.
    That's why Smith Micro normally provides a separate QM installer for remotes with a Ppro release. Only they didn't do that with 11.1.

    So I was driving home today after a yummy and sunny Italian lunch today, and thought "Why not try..[....]...it ain't working now so what can you actually break?"

    So I tested my thought, and have just received back both renders I sent out to two remotes.

    My setup: main machine and a VMWare ESXi rackserver (to fit in datacenters) on which you can run virtual machines as if they where actual PC's. On the server I have two Win7 PC's (Win 7 is my OS of choice as I think Win10 is pathetic - (I use Win10 on a Tablet with daily annoyances).

    On both Win 7 PC's I had installed the queuemanager, but had never seen them work as I had upgraded to 11.1 before I could try them out.

    I the end what I did was quite simple:

    1. you have already installed QM on the remote PC, so any links needed in the Win registry (if any) are present

    2. There has to be a piece of code that checks the build numbers (or version numbers, as you will). That piece of code has to jump in during the communications setup between the main QM and the remote QM's. So it seemed unlikely the Win registry would contain a version number that would play a role here.

    3. Locate where your Queue Manager is installed on your remote PC
      A typical Win setup would be:
      C:\Program Files\Smith Micro\Queue Manager 11
      "Program Files" stores the 64bits programs, and Program Files (x86)" the 32 bits. I always have Poser install the 32 bit stuff as well, although I never use it. 32 bit was mainstream until very recently and SOMETIMES a 32 bit version can still do a little bit more than the 64 bit version, or work better with other programs. With Poser this is not the case AFAIK, but Microsoft for example still advises you the install the 32bit version of Office, even if you have a 64bit PC.
      I left alone the subdirs in the QM subdir (Documentation, Runtime, uninstall)

    1. Going into the QM directory you found in (3) (On the remote PC):
      Move out ALL the files present in that QM subdir. Again: this is for "Program Files", so the 64 bit version. I didn't bother with the 32 bit install of QM in "Program Files (x86)", as I do only 64bit with Poser.
      But if for some reason you use Poser 32bits, the same would apply, only then in "Program Files (x86)".
      I moved all those files into a new folder I made in the Smith Micro folder, i.e. 'ORG QM11', so I can always revert if needed.

    2. Then, on your main Poser machine, locate your install of Poser. The master Runtime so to say. I had mine installed on the C-drive as that is an SSD, but not in "Program Files" or "Program Files (x86)". That's an aspect I really like about Poser, you can place your main runtime anywhere it's convenient.
      I had mine installed in C:\PP2016.
      Now, if you go to the x64 subdir and then Poser 11, if you look carefully, you'll see ALL the filenames present of ALL the files you just moved out in step 4. COPY ALL those matching filenames to the remote machine and into the directory you just cleaned out.
      (You could probably just copy everthing, but I didn't test that, I did a one on one copy of the exact filenames I had moved out.

    Make sure Poser and/or QM is not running on your main machine. At least mine didn't copy everything correctly until I had stopped Poser.

    Again: this is for 64 bits, but if you would go to the x86 subdir you can do the same for 32 bits. But this I haven't tested.

    1. Final step: you are set up! Make a link on your desktop to the new Queuemanager.exe (old links will probably keep working, but this one is certain to work). Copy that link into your All Users startup folder and QM will start up automatically when you start that PC.
      For now just start up QM on your main machine and doubleclick your newly created desktop link and the remote QM will start up as well.
      You'll see your main QM mumbling something about extra proc queues or something.
      I tested it by telling the main QM not to process jobs locally, and just send and accept jobs to/from network.

    As I can't compare with how network queues 'Normally' worked, all I can say is. It works. It's not fast, as all textures etc need to be sent to the remote machine. But it works.
    The program items that are located in the 64bit QM 11 subfolder of the remote machine.

    0_1531507599669_QM112QM11.1-32 bits.jpg

    The program items that are located in the 32bit QM 11 subfolder of the remote machine.

    And all those program items are located in your main install in 'x64\Poser 11' (64 bits) or 'X86\Poser 11' (32 bits)

  • Thanks @BobM this might even be worth trying on macOS! I'd be interested to hear whether @seachnasaigh has success with this method.

  • @BobM Maybe step 1 and step 2 seem a bit cryptic, but I'm not allowed to edit my own post after 3 minutes when posted:

    Step 1 means: you have already installed QM from an official SM package and have had it up and running (although not working with the 11.1 QM on your main).

    • entries, links and other stuff are correctly put into
      a) the Win registry and/or in
      b) .ini and/or in
      c) .xml files elsewhere on your system the QM uses to startup.
    • to be honest I don't think SM uses the Win registry, but puts it's startup stuff in .xml and .ini files, and that's a very good thing. That way Poser remains as independent as possible from the OS
    • you have entered your QM key successfully

    Step 2 Is my musing about when and where it would be decided if the two QM build numbers match or not, and thus if this method would work. It is not relevant as a step to take.

    While at first I didn't really understand the importance of the matching build numbers, it's probably because that way - if new functionality or communication protocols or whatever are added to the QM - it's a surefire way to check that both QM's will be able to work together.