Happy Independence Day from all of us at the Connect IT Community! Our US offices will be closed on Monday, July 4th, 2022 in recognition of the holiday. Limited Support staff in the US will be on-call and available for critical Service(s) Down issues only. Normal Support operations in the US will resume on Tuesday, July 5th, 2022.

Office 365 Installer

2»

Comments

  • Miguel Aleman
    Miguel Aleman Member
    edited February 2019

    Quinn-

    I have identified a few urls that are being blocked by our webfilter, although i get a success flag return on the procedure i am assuming that this could be a problem?


    officecdn.microsoft.com

    client-office365-tas.msedge.net

    a-0020.a-msedge.net

    webshell.suite.office.com


  • Jeffrey Greenberg
    edited May 2019

    Quinn - Thank you for this procedure, it saved us a lot of time in deployment.  Do you happen to know what the behavior will be if this is run against a workstation that already has a deployment of Office 365?  Will it just silently fail or attempt to re-install office?


    Thanks again.

  • Jeffrey Greenberg
    edited May 2019

    Quinn - Thank you for this procedure, it saved us a lot of time in deployment.  Do you happen to know what the behavior will be if this is run against a workstation that already has a deployment of Office 365?  Will it just silently fail or attempt to re-install office?


    Thanks again.

  • Quinn Van Order
    edited May 2019

    If applicable, it will attempt an in place upgrade. Otherwise the procedure will complete, while nothing will have been done. Refer to the office install logs for post script assessment. 

  • Quinn Van Order
    edited May 2019

    @Patrick, verify that you set *all* options to constant, when scheduling a procedure there is a separate and easy to miss tab to provide script input.

    Kaseya treats procedure variables dumbly; when you declare them, if you give them a null value, Kaseya does not create a null valued variable, it creates nothing. So if a procedure is expecting some input, a lot of things can fall apart because expected values don't even exist. With how I utilize variables in this script, it can result in an attempt to execute malformed powershell commands. 

    Furthermore, Kaseya treats any line executing as success. This has no bearing on actual success. So if Kaseya is able to simply *fire off the line of code*, regardless of the 11 billion subsequent errors, it treats it as a success and continues on. Thus you can have procedures that report success but actually did nothing at all. 

    One thing to do as a test would be to have the temp directory open, as well as the windows ResMon application. When this procedure fires off, if it is working you should see the directory created, the c2r toolkit being dropped into place, and then an extended spike in network usage for a few minutes as it downloads. From there, you will see network drop off, and CPU/ Disk spike until completion. Not seeing logs in particular is suspicious. Do you see the logs post install with the manual run now? 

    What does the Kaseya procedure logs themselves say? Generally I have the procedure log the values it gets, so you should see log entries like "user selected <office product>"... do you see those when it fails? 

  • Quinn Van Order
    edited May 2019

    @Miguel, as mentioned in my post above, a script reporting success only means it was able to fire off each line. I assume by your post that you are seeing a success report, and the end result is no program installed. If you have web filtering in place, I would suggest you do a manual run of the office c2r toolkit with your network monitoring tools open so you can see what is blocked. If the script reports success and then does nothing, that means that at the least, the critical components were correctly linked (eg did you correctly upload the c2r components and the config file). The office install log may have useful information, see the main description of this procedure to see the logging path. The procedure logs within Kaseya will probably be less useful, as the procedure did succeed. 


    In general, seeing the script report success and nothing happened always means 1 of 2 things. 1) Something is interfering with the network connection from the c2r toolkit and Msft HQ, or 2) There is some conflict on the local workstation blocking the install. For that, see the office install logs and refer to Microsoft for further support. 

  • Brian Sorrells
    edited July 2019

    You were kind enough to respond to a direct message so I thought I'd share your response here for others to see.

    Q:  I was wondering if
    you could tell me how to force it to always install the 64bit version of
    office?


    A:  If you edit the procedure, the top lines are indicated with comments where you can safely alter them. Simply alter any line you wish to hardcode from "prompt when procedure is scheduled" to "Constant value" and input the value you wish.