Donate Now Goal amount for this year: 2500 USD, Received: 1627 USD (65%)

Results 1 to 9 of 9
Like Tree8Likes
  • 4 Post By Twiceroadsfool
  • 3 Post By Twiceroadsfool
  • 1 Post By Twiceroadsfool

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

  1.    #1
    Junior Member
    Join Date
    November 27, 2013
    Posts
    33
    Current Local Time
    10:52 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,187
    Current Local Time
    09:52 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
    33
    Current Local Time
    10:52 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:

    Personal Accelerator - What is it & Why a Separate Update?-pacr-settings.png


    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
    Junior Member kraftwerk's Avatar
    Join Date
    November 1, 2012
    Location
    St. Louis, MO
    Posts
    42
    Current Local Time
    09:52 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,187
    Current Local Time
    09:52 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:	14 
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,783
    Current Local Time
    07:52 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,187
    Current Local Time
    09:52 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,783
    Current Local Time
    07:52 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,187
    Current Local Time
    09:52 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
    johnp likes this.

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
  •