|
NevergirlsOFFICIAL posted:The other thing to note is this won't uninstall existing Office versions for you. So you'll need to make a script that uninstalls the old version of office, and then runs clicktorun. If you need any help with this kind of script, let me know. I have a script utilizing the Powershell Application Deployment Toolkit that uninstalls all versions of Office (2003, 2007, 2010, 2013, 2012 Click to Run, and 365) and then installs Office 365 (whatever version depending on the installation xml). This has proved to be a huge time saver as I am the "resource" at my MSP for Office 365 migrations. Automates the entire process so the user can click to begin and then forces them to restart afterward with a prompt.
|
#
¿
Sep 4, 2015 20:56
|
|
|
|
| # ¿ May 3, 2024 06:43 |
|
|
NevergirlsOFFICIAL posted:I want your script please. It sounds much better than my batch file that calls that vbscript thing that kills office (you know the one I'm talking about). It works but I have to change it for each version of Office depending on where I am. Gerdalti posted:Another vote for please share. I won't need it for a few months, but it sounds awesome. https://github.com/doxinho/officedeployment It's actually the same thing you're using, just with a nifty wrapper and dialog prompts... but it gets the job done pretty well. quote:# Office 2010 (32-bit) The next step is to fully automate this with the various RMM tools. I've had difficulty doing this with the prompts because it needs to run as the user context and SCCM seems most suited for that. The PSADT is primarily built for use with SCCM. In my case, I haven't been completely successful running it silently with Kaseya but I'm going to continue working at it. My general use case is just dropping it on a network share, kicking it it off via the .exe and letting users finish it. dox fucked around with this message at 05:47 on Sep 6, 2015 |
|
#
¿
Sep 6, 2015 05:37
|
|
|
socialsecurity posted:No business should run the bloated OS installs that companies sell you, make a nice prepped clean image. You're living in fantasy land. It seems a lot of businesses under 75-100 users buy OEM machines and manually set them up, especially if they are serviced by an MSP. It's just too much overhead to maintain a unique image for each client, not to mention the fact that clients think buying a volume license of Windows isn't beneficial. What you do in this case is use MDT with a variety of scripts (such as my HP Bloatware removal script) and it automates the entire setup process (Ninite, bloatware removal, updates) as a Post-OS Install Task Sequence. For those of you interested, here is my HP Bloatware Removal Powershell script.
|
|
#
¿
Sep 11, 2015 15:28
|
|
|
socialsecurity posted:I work for a msp and this is exactly what we do its not that bad at all even for our small clients. You don't even need volume licensing we just use abr to migrate the activations automatically. Mdt or wds don't take long at all to setup and the benefits are worth it. So do you need to go through OOBE on new machines, use abr to backup the license, then image, and apply abr manually? As far as I know, this isn't compliant with Microsoft due to the fact that you need at least one Volume License per edition to acquire "reimaging rights" which seems to be installing anything other than original media... so that's why we haven't done this. Guess it just boils down to whether you care about that (and if they'd ever know). Potato Alley posted:Who the hell said unique image? No, I totally agree... a generic image would work great if all clients purchased volume licensing- I guess it just boils down to that. We're had a few dozen I've both setup MDT for internally or had them purchase one license and use our MDT server, but that's usually for a mass deployments (20+). dox fucked around with this message at 03:32 on Sep 12, 2015 |
|
#
¿
Sep 12, 2015 03:23
|
|