Donate Now Goal amount for this year: 2500 USD, Received: 2174 USD (87%)

Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Personal Accelerator - What is it & Why a Separate Update?

  1. #1
    Junior Member
    Join Date
    November 27, 2013
    Posts
    34
    Current Local Time
    10:19 AM

    Personal Accelerator - What is it & Why a Separate Update?

    I see there are updates foe Personal Accelerator available to me. I thought this was something that was built into Revit?

    1) Why is it a separate update?
    2) Do the latest Revit Updates include the updates to Personal Accelerator?
    3) If my employees are all on the latest Revit Build, and I don't push out these separate Personal Accelerator updates to my office, is everyone going to suddenly lose access to BIM 360 soon?

    This whole thing seems abnormal compared to previous updates - I would have expected a bit more hand-holding by Autodesk to clarify all of it.
    Anyway - any help you all can give would be greatly appreciated.
    Thanks!

  2. #2
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,410
    Current Local Time
    09:19 AM
    1. Long story short: The separate PACR.msi installer is for users that ONLY have 2019 or 2020 installed, meaning they arent installing any of the other updates. PACR is a Shared Resource, so once you install ANY of the other updates (2017.2.5, or 2018.3.3, or 2019.2.1(, your PACR version will be 20.0.9, which is current.

    2. The latest updates (2017.2.5, 2018.3.3, 2019.2.1) DO include the PACR update. You dont need to run the PACR msi after those updates.

    3. If by LATEST build, you mean 2017.2.5, 2018.3.3, or 2019.2.1, they will be fine and not lose access to BIM360. if they are on 2017.2.4, 2018.3.2, or 2019.2, i would expect them to lose access.

    Also, something to keep in mind:

    ***IF*** you run your deployments with a scripted solution (PDQ, PxTools, SCCM, CMD), installing the updates with PACR updated (like 2017.2.5) will make an earlier deployment of a different product (like your original 2018 or 2019 deployment) fail to complete, because the silenced installer for the old PACR doesnt know how to skip the PACR install without throwing a window on the screen (which it cant, as its run silently).

    There is a fix for it, so we wanted to make you aware of it: You can edit the INI files of your original 2017, 2018, and 2019 deployments, as follows:


    1. Find the PACR subsection of the INI file.
    2. Add a line for IGNORE_FAILURE=YES
    3. Change the ROLLBACKABLE line from YES to NO.


    Keep in mind: This problem wont rear its head while patching existing workstations, as the versions of Revit are all installed already. It is when you go to deploy to a new machine (and have added these patches in) that you will see these failures.

  3. #3
    Junior Member
    Join Date
    November 27, 2013
    Posts
    34
    Current Local Time
    10:19 AM
    THANK YOU!!! THANK YOU!!! THANK YOU!!!!
    This whole thing seems to make so much more sense now.


    So... If i understand correctly - the problematic scenario that requires manually modifying an ini file would be like this:
    Employee 24601 has Revit 2017 & 2018 installed. Both have been updated to their latest builds (2017.2.5 & 2018.3.3, respectively). Employee 24601 asks for Revit 2019 to be installed on his machine. I try to run my 2019 deployment, and it fails because the base 2019 deployment attempts to install the out of the box version of Revit, prior to updating it to the latest update (2019.2.1)

    To resolve the problem, I need to modify the PACR section of the image64.ini file (in the Img folder of the deployment) to look like:

    Click image for larger version. 

Name:	PACR settings.png 
Views:	27 
Size:	35.3 KB 
ID:	36819


    Out of curiosity - were you able to figure all of this out on your own based on what Autodesk published in their update announcements? Or did this understanding come form separate, follow-up conversations with Autodesk?

  4. #4
    Member kraftwerk's Avatar
    Join Date
    November 1, 2012
    Location
    St. Louis, MO
    Posts
    55
    Current Local Time
    09:19 AM
    Beautiful. I ran into this problem five minutes ago with an existing workstation. Uninstalling the PACR and then deleting the Registry Keys per this link, Autodesk Forum, solved the trick.

    As I'm looking to deploy to some machines soon, this is very timely.

  5. #5
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,410
    Current Local Time
    09:19 AM
    Quote Originally Posted by nharburger View Post
    THANK YOU!!! THANK YOU!!! THANK YOU!!!!
    This whole thing seems to make so much more sense now.


    So... If i understand correctly - the problematic scenario that requires manually modifying an ini file would be like this:
    Employee 24601 has Revit 2017 & 2018 installed. Both have been updated to their latest builds (2017.2.5 & 2018.3.3, respectively). Employee 24601 asks for Revit 2019 to be installed on his machine. I try to run my 2019 deployment, and it fails because the base 2019 deployment attempts to install the out of the box version of Revit, prior to updating it to the latest update (2019.2.1)

    To resolve the problem, I need to modify the PACR section of the image64.ini file (in the Img folder of the deployment) to look like:

    Click image for larger version. 

Name:	PACR settings.png 
Views:	27 
Size:	35.3 KB 
ID:	36819
    I cant say for sure that the file you need to edit is image64.ini. Its the one that is named the same thing as your deployment. Mine is named RVT2019.ini, for instance. There are TWO ini files present: Yours, and the default Autodesk one that it stashes there, for some reason. You need to edit the one that is named the same thing as your deployment.

    Out of curiosity - were you able to figure all of this out on your own based on what Autodesk published in their update announcements? Or did this understanding come form separate, follow-up conversations with Autodesk?
    I didnt get the information from Autodesk. I actually sent what i had found TO Autodesk, and had a follow up meeting with them this morning, to show them what i had found. Gordon Price has been doing an ENORMOUS amount of testing, to figure out what conditions work and what conditions dont. But my road to understanding went like this:

    1. I got a call (late last week) from a client that was trying to deploy to a NEW machine, and 2018 and 2019 both had strange failures.

    2. Given the failures they had, i had (at the time) attributed it to an IT mistake, with the deployments. We had to manually kludge some stuff to fix that machine, but once it was fixed, we shrugged it off.

    3. A couple hours after fixing that clients machine, ANOTHER client pinged me with a failure for 2019 to deploy. I started to get edgy about the cause.

    4. I have always (and have always recommended it to the entire revit community) tested all of my point releases and deployments on a Virtual machine, prior to releasing it on production machines. The value of this CANNOT be overstated. There are MANY things to test, prior to rollout. SO, i got on my Test VM, and set it to *current status* of my machines (2017.2.4, 2018.3.2, 2019.2). Then i rolled out the updates. As expected, they all went perfectly fine.

    5. Next step: Now that the "updates" were PART of my rollout package, set the Test VM back to square 1 (no autodesk software), and tell it to roll out EVERYTHING, to see what happens.

    2017 = Succeed
    2017SP1 = Succeed
    2017SP2 = Succeed
    2017.1 = Succeed
    2017.1.1 = Succeed
    2017.2 = Succeed
    2017.2.1 = Succeed
    2017.2.3 = Succeed
    2017.2.4 = Succeed
    2017.2.5 = Succeed
    2018 = Fail (all 2018 processes abort because of this)
    2019 = Fail (all 2019 processes abort because of this)

    Checking the 2018 and 2019 Deployment Logs, the installations of Revit succeeded, and a Postrequisite install of PACR failed. Then the Revit Deployment rolled itself back, because of the postreq PACR failure. Thats all just written in the logs, for the Revit deployments.

    It makes sense, as the PACR in the deployment for Revit 2018 was the one included with the 2018 deployment 2 years ago, and the one from 2019 is from a year ago. So the trick was to make the deployments skip over the failure.

    This was a massive issue with C++ redistributables, in many years of Autodesk deployments. So back in the day, we would set the C++ redist's to IGNORE_FAILURE=YES, to work around the issues. Same with .NET prereq's.

    6. Retry entire run, with IGNORE_FAILURE=YES and ROLLBACKABLE=NO set for PACR in the Deployments. Now all of 2018 (including latest update) and all of 2019 (including latest update) succeed.

    I checked the log for the deployments, and (of course) the PACR installs still fail within 2018 and 2019, but the Failure is ignored, and bypassed.

    7. I spoke with Autodesk on a conference call this morning, as they ARE NOT seeing the same failures that we are (or they obviously would have done something about it). The difference *APPEARS* to be (not fully validated yet) that my installs run silently, through a scripting mechanism. When they test the deployments internally, they launch them manually with full UI, and the deployment doesnt roll itself back. So our best guess is that the older PACR MSI doesnt have a way to bypass the Failure WHEN its in silent mode.

    Autodesk HAS said they are changing this in the future releases of Revit, so that a failed PACR install wont tank the deployment. And that the PACR MSI should be able to handle a silent error trap, and that they are looking in to it.

    8. Rerun entire test, with 2020 on the heels of all of the previous tests. This was really my goal, obviously. But i couldnt test 2020 in good faith, until i was sure earlier stuff wasnt complicating it. The 2020 portion of the test went off without a hitch. So my test VM now properly has patched 2016, 2017, 2018, 2019, and 2020.

    9. Using the VM to prep libraries, templates, and other materials. Those need to be there to vet the FULL install script, since some of that is needed by the install routine. Once thats done, i will:

    10. Run one final test on the VM, with everything. Hoping for a perfect result (ETA tonight). After thats done, its GO TIME on installs.
    Last edited by Twiceroadsfool; June 11th, 2019 at 03:55 PM.

  6. #6
    The Moderator with No Imagination MPwuzhere's Avatar
    Join Date
    December 14, 2010
    Location
    Coeur d Alene, ID
    Posts
    4,824
    Current Local Time
    07:19 AM
    Don't know if it makes a difference with your scripts....but the 2019 update forced me to reboot my machines before I could install anything else.

  7. #7
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,410
    Current Local Time
    09:19 AM
    Thats common for a lot of the installers, and solvable, with things like the Px Tools. You can mute that restart until after everything is done.

  8. #8
    The Moderator with No Imagination MPwuzhere's Avatar
    Join Date
    December 14, 2010
    Location
    Coeur d Alene, ID
    Posts
    4,824
    Current Local Time
    07:19 AM
    Yeah, too expensive with only 10 workstations....Gordon and I chatted about it a while back.

  9. #9
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,410
    Current Local Time
    09:19 AM
    Quote Originally Posted by MPwuzhere View Post
    Yeah, too expensive with only 10 workstations....Gordon and I chatted about it a while back.
    Well, that's a different thread. There are so many steps in our deployment, I'm betting someone couldn't do ten machines and get them all right.

    FWIW I think we're at 12 machines total (physical and virtual) and it's way worth it.

    Sent from my Pixel 3 XL using Tapatalk

  10.    #10
    Moderator snowyweston's Avatar
    Join Date
    December 21, 2010
    Location
    C.LONDON
    Posts
    4,408
    Current Local Time
    03:19 PM
    So somehow one of our machines (that I thought good, and aligned to others of its kind) has just thrown up this problem attempting to install 2019.2.2 and I got a quick quiz... which .ini of the deployment? Setup?

    edit

    Ignore that, should've read the thread better.

    Setup.ini tweaked and redeployed, but still the hotfix pukes about a network resource not being available.

    ...but I think I'm dealing with something different... in that, I can't uninstall the Personal Accelerator (or for that matter ANY Autodesk product) - getting some noise about "Allied products"...

    Click image for larger version. 

Name:	allied.png 
Views:	8 
Size:	26.7 KB 
ID:	37366





    I've another machine I can switcheroo for this one - but so very bored of all this.
    Last edited by snowyweston; September 4th, 2019 at 02:45 PM.

Similar Threads

  1. My Revit is starting to get personal.
    By Scott Deslippe in forum Architecture and General Revit Questions
    Replies: 1
    Last Post: November 14th, 2013, 03:31 PM
  2. New Personal Rig
    By ralph in forum Hardware and Infrastructure
    Replies: 2
    Last Post: May 20th, 2013, 01:21 PM
  3. separate walls separate colors /
    By Tom Dolle in forum Architecture and General Revit Questions
    Replies: 24
    Last Post: October 26th, 2012, 10:38 PM
  4. Personal Preferences on Keynotes?
    By Alexander_J_Hicks in forum Architecture and General Revit Questions
    Replies: 1
    Last Post: June 7th, 2012, 04:15 PM
  5. Personal Profile : Signature
    By brinxb in forum Out There
    Replies: 8
    Last Post: February 23rd, 2012, 02:06 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •