Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Seth last won the day on September 1

Seth had the most liked content!

Community Reputation

1 Neutral

My Information

  • Agent Count
    Less than 100

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It seems to be working in ours - v19.0.203
  2. This can either be deleted, or once I get it working - I can post the success in here for future Global VPN Using-Admins. But, I realized...my approach was wrong from the very start. And, it's best that we sweep such embarrassments as far under the wrong as possible.
  3. That's odd; they're showing on my end. You might need to refresh your browser cache?
  4. Sorry guys; re-upped the pictures 👍
  5. If this is already a topic, I apologize - I did a search, but couldn't find one. Over the weekend, we had a Hyper-V Guest go down due to space issues on the host. We did get an alert/ticket for the Guest Server going offline, but we have none for the space issues on the host. When I went into to the Effective Policy Data Tile, under Remote Monitors, I noticed that the "Disk - [C:] Drive Space Critical-[SERVER](AgentID)" Remote Monitor was not listed. That would certainly explain why there was no alert/ticket. Now, the question is - why isn't this monitor on this Server? I checked the other Hyper-V host at this location, and it's not on there, either. So I checked another Server, from another Client/Location, and it has the Remote Monitor (and, a lot more groups). Now, the two Servers that do not have the monitor are Windows Server 2016, while the Server that does have the Remote Monitor, is a 2008 R2. But, I checked with someone else who has a couple 2016 Servers Deployed, and when they checked, the Remote Monitor in question was there. So, I'm thinking it's probably not the Server OS. So, then I checked the Commands Data Tile, and found ~5 Monitor Install commands with a Status of 'Failed'. It doesn't say which monitor, so I'm not sure if it's the monitor...but, if monitor installs are failing...and this doesn't have a monitor...I can't help but think that whatever's causing the failures, is also preventing this monitor from getting installed? Unfortunately, I know p much nothing about non-Internal Monitors. It's my understanding that LabTech has Default Remote Monitors (which, according to LT's 'Default Remote Monitors' Documentation, these don't appear to be a part of), and Ignite has it's own Default Monitors (but, they appear to all be CPU-related?), and Plugins come with their own monitors. So...I have no idea if this is a group problem, an install problem, an OS problem, or what. Monitor Install Parameters: 1356525||6|6|300|eq 1|*!!! 0!!!%Sever Administrator%!!! eventlogs.EventID IN (2058,2067,2076,2085,2114,2115,21 92,2235,2341,2342,2343,2396,2397)! !!|1|False|0 Monitor Install Output: ERR Microsoft.VisualBasic Conversion from string "eventlogs.EventID IN (2058,2067," to type 'Integer' is not valid. And the install command is a MySQL Query, I guess? Whole thing is pretty confusing, but now I'm paranoid that we have a bunch of servers missing a bunch of monitors, and...just need a place to start in getting this whole rat's nest straightened out, I guess.
  6. Seth

    Prompt User for Input

    Hmmm...this opens up quite a few interesting possibilities. I'll have to figure out whether it'd be better to have an initial script, setting the EDFs from the parameters, then go into the rest of the script - or, use the parameters for if the EDF's are empty - or...not even deal with EDF's. Either way, this is going to be a very helpful game-changer - thanks!
  7. You could use the Warranty Manager Plugin from the SolultionCenter. But it's currently at End-of-Life status, so I don't know how reliable it is, or will continue to be. Or, you could get an API key from Dell (assuming your PC's are Dells), and then script a method of getting/storing the Warranty Information from Dell directly (the method I had been toying with was co-opted by two guys way smarter than me: Mark Godfrey and Gary Block). Or, you could pay the guys at Warranty Master.
  8. Does anyone know if there's a way to prompt whoever is running the script for information that would then be passed into the script? I'm working on my AutoDeploy idea/nightmare, and had initially wanted a way of having a LT User fill out some kind of simple-yet-idiot-proof form that would serve to provide all the required information for the EDF's/Script - but I know absolutely 0 C#, and even less VB, so there goes writing a plugin. After a couple weeks of tweaking Google Searches, I've come to the conclusion that there is no plugin that would fall under a "Custom Forms" type of Category. So, before I just commit Seppuku with my keyboard, I thought I'd at least check and see if there's a way to have the script itself prompt the LT User for the input. It wouldn't be a single-form layout, but a Step-by-Step "Wizard" of prompts wouldn't be too far off the mark. Googling this has yielded nothing but further disdain for CW's documentation for LabTech.
  9. Who would've thought, the simple act of authenticating with an email address and a password would be such an undertaking. I appreciate you sharing all of this, it looks like you spent a lot of time piecing it all together. The office365_install.zip link appears to be broken, but I was able to pull up the rest - now I just need to dissect, and figure out how to employ this in a workable solution for us (if I'm capable of understanding it). When I get the time, I'll also be sure to update my Acrobat Script (and, at some point, the whole thing - in case it could be useful to someone else), but right now I've had to kind of pick it apart and make some positioning changes to account for other scripts that might be run alongside of the existing scripts. I've also got a (very basic) AutoHotKey.exe that can launch Acrobat (DC 2015 Pro, anyway - haven't tested the others) and move through the Registration Prompts after install. Regrettably, my timing seems a bit off, and it's a tricky bugger to tweak, since the registration prompts for a brand new installation are different than for a re-registration, or registration on a PC where Acrobat has been installed previously. So, it's almost a "try - wipe - retry" process. But so far, script will do all the typical default PC setup stuff, then it will Install Office 365 (pin to taskbar is hit-or-miss), Install Acrobat DC 2015 Pro, and then Auto-Register it (but it will miss the 'Set as Default PDF Viewer' prompts, and wind up opening up Windows Explorer, and navigate randomly while the ahk script finishes out). So...close, but ghetto-rigged, and still p far.
  10. I don't know where I'd be without you, DarrenWhite99, and TBH I'm not sure I want to know. I had neglected to perform the Generate Transform... command in the Customization Wizards (or, point to it in my msiexec /i commands, for that matter). But I noticed that the Transform Files I was replacing today, in light of the information you provided, all had 'Last Modified' timestamps that lined up with when I last modified/saved the packages. So, if the Transform Files were being auto-generated as part of the Save Package process, then one would assume that running the setup.exe would've called the msi with the mst, and things should have worked. But, I mean...if everything that 'should' work did work, Lord knows I'd be out of a job quick, fast, and in a hurry. So, I went ahead and Generated Transform files for each package, and will try the msiexec method, with the Transforms, and see what that does. As for the the Registry adjustments, I'm 100% on board - that's usually how I'd prefer to do things (due to my very limited, next to 0, understanding of the finer points of installation processes) - so, I'll be trying that next if the results of the next test aren't desirable. Will update with results (and full details of any method that proves successful, for anyone who's interested). Also - since I'm becoming more and more convinced that there's nothing you don't know (and it will invariably be the next thread I create)...do you have any info regarding the silent deployment of Office (both standalone and 365), with activation/registration using variables? If so, that would I'd be even further in your debt/grateful (whatever's beyond 'eternally', as you've already been an immense help to me in a myriad of ways). Update After calling the Transform file with the msiexec install command, I can confirm that the silent installation works. However, prompt for Registration/Sign-In w/Adobe ID still not suppressed. Ideally, would love an option to automatically Register/Sign-In w/Adobe ID (as we have a general account per client) - but I cannot figure out how to do that, without supplying the SerialNumber in the Transform file (for DC, anyway - not sure if it's the same for 9, X, or XI). And, unfortunately, not everyone uses the same Serial Number, as Acrobat is bought on an as-needed basis, more often than not. The other thing I'm going to have to figure out, is whether or not De-Activation/Registration can be performed via command-line, since users are often times going to be bringing a key from their existing PC to their new one. And, I don't know if Adobe's gotten better about it - but I remember back in the days of 8 Pro, that if your PC crashed, and you tried to re-install Acrobat on a new PC with the same key, it involved a long phone conversation with multiple levels of Adobe Technical support, explaining that you couldn't deactivate on the PC with the busted HDD. But, that'll be a bridge to cross once the installation/registration deployment has been solidified. So, for anyone who's curious - here's what I did in order to get it so that the program would install silently (bearing in mind that the Registration Suppression is still not showing any success)
  11. Has anyone found a way to successfully automate the installation of Adobe Acrobat? If so, I'd very much like to pick your brain. We have clients with a wide range of versions - from 9.0 (some have 8, but they're just S.O.L.) to DC 2017; both Standard and Pro, and some with volume licenses, others with standalone licenses (fun, right)? So what I did, which may or may not be best practices, is as follows (will try to be as concise as possible): * Created Checkbox EDF's at the Computer level for each version (ex: "Install Acrobat 9 Pro?") * Created Text EDF at the Computer level for the Product Key (cuz, I'm doubting they are going to be installing multiple versions) * Created Text EDF's at the Location level for the Product Key, per version (ex: "Acrobat 9 Pro Key") Then I created a script to run with the deployment scripts I have, which will check Computer level EDF's - if not checked, skip...if checked, go to Install. The Install script will check the Computer Level EDF's for the Acrobat Key, if it's blank, it will check the Location level EDF's for the appropriate version of Adobe, to see if there's a volume license present. It will store the key in a variable that will later be passed to the install command. Then it will download a .ZIP archive containing a customized install package for the appropriate version, that I made with the Adobe Customization Wizard. I essentially just used the Adobe Customization Wizard to run the installer silently, set Acrobat as the Default PDF Program, Suppress the EULA, Install the Certificate silently, and Disable Registration Prompt. The Product Key, and the Company Name will be set on the command line, like so: msiexec.exe /i <path\to\AcroPro.msi> ISX_SERIALNUMBER="@AcrobatKey@" COMPANY="%clientname%" /qn (I added the "/qn" just to be doubly-sure it runs quietly) I ran the script on my test PC (windows 10), and verified that it is downloading the appropriate installer package, and extracting it correctly, and that msiexec is showing in the tasklist. However, after about 1 hour of letting it run, it still had not installed. Msiexec was still in the tasklist, but more than an hour to install Acrobat DC 2015 Pro on a brand new machine? Looking around the Adobe Documentation, it's incredibly vague - it says that, if you use the Customization Wizard, all you have to do is run the .exe. But then it says that if you are running the .exe, you have to tell it to look at the .ini file (which points at the .mst file). But then, most of their examples are using the .msi, which requires you to point at the .mst file that was created when you customized the package. And then they say that the .mst file is just for Transforms, and should only be used if Acrobat is already installed and you're installing an update or something. Well, I'm only looking to do fresh installs, so by that logic, the .mst file is not of my concern, right? So, to test, I logged on to the test PC I'm working with, and ran the msiexec command - hung again. Then I ran the setup.exe command: <path\to\setup.exe> /sAll /msi /norestart ISX_SERIALNUMBER="<product-key>" COMPANY="<clientname>" EULA_ACCEPT="YES" REGISTRATION_SUPPRESS="YES" Added the /sAll to silence everything (even though it should be silent from the Customization Wizard....I have trust issues) Added the /msi to pass msiexec switches/options Added the Properties for Eula Acceptance and Registration Prompt Suppression (again...trying to cover all the bases) Acrobat DC Pro installed silently. In only a couple minutes. Maybe longer, but it certainly didn't take an hour or more. I launched Acrobat to verify that it was activated, and that Registration Prompt would be suppressed. Registration Prompt was not suppressed. It was set to be suppressed inside the package, using the Customization Wizard, as well as on the command line that installed the program. Acrobat was also not configured to be the Default Program, despite setting it to be in the Customization Wizard. So, I then thought to myself "maybe setting the options in the Configuration Wizard AND on the command line was throwing it for a loop" and I run the following: <path\to\setup.exe> /ini "<path\to\setup.ini>" /msi ISX_SERIALNUMBER="<product-key>" COMPANY="<company-name>" Not at all silent. Contents of the .ini file are: [Startup] RequireOS=Windows 7 RequireMSI=3.1 RequireIE=7.0.0000.0 Require64BitVCRT=1 CmdLine=/sall /rs [Product] PATCH=Acrobat2015Upd1500630279.msp msi=AcroPro.msi vcrtMsi=vc_runtimeMinimum_x64.msi vcrtDir=VCRT_x64 vcrtCommandLine=VSEXTUI=1 Languages=2052;1028;1029;1030;1043;1033;1035;1036;1031;1038;1040;1041;1042;1044;1045;1046;1049;1051;1060;1034;1053;1055;1058;1025;1037;6156 2052=Chinese Simplified 1028=Chinese Traditional 1029=Czech 1030=Danish 1043=Dutch (Netherlands) 1033=English (United States) 1035=Finnish 1036=French (France) 1031=German (Germany) 1038=Hungarian 1040=Italian (Italy) 1041=Japanese 1042=Korean 1044=Norwegian (Bokmal) 1045=Polish 1046=Portuguese (Brazil) 1049=Russian 1051=Slovak 1060=Slovenian 1034=Spanish (Traditional Sort) 1053=Swedish 1055=Turkish 1058=Ukrainian 1025=English with Arabic support 1037=English with Hebrew support 6156=French (Morocco) CmdLine=TRANSFORMS="AcroPro.mst" [Windows 7] PlatformID=2 MajorVersion=6 MinorVersion=1 [MSI Updater] Path=WindowsInstaller-KB893803-v2-x86.exe So, by declaring the .ini file - the executable should have ran with /sAll, and didn't. Which doesn't make me feel too good about any of the other changes that were saved to the Package. The Product Key was populated, but that was set in the commandline. Not all of the options I've set in the Customization Wizard can be set from the Command Line, and even then - we saw what happend with the Registration Suppression. Most everyone else on the internet, who are posting in support forums and the like, seem to do this without any problem, so I have a sneaking suspicion it's just me. But, if I can get this puppy working - then all that will be left (for now) is an Office deployment script (which I'm already dreading, since they don't even put out Customization Wizards for depoyment >__<). Oh, and I can also post the LT script I'm using if that helps (or, if we get this working, and then someone else wants it).
  12. Ahhhhh...yep! We were on Patch 11. Upgraded to Patch 18, and EDF Values are appearing correctly. Thanks, Thodges!
  13. Well, crap - the logged %powershellresult% has the appropriate amount of '\'s in it. However, when I used the command you gave to replace '\\\\' with '\' it changed the EDF value to \\SERVER\\RedirectedFodlers\\user\\My Documents So, I thought I'd try to replace '\\' with '\' - and then it went right back to \\\\SERVER\\RedirectedFolders\\user\\My Documents And then, for fun, I tried replacing '\\\' with '\' and got The regular expression pattern \\\\\\ is not valid. At line:1 char:1 + ((Get-WmiObject -Namespace root\\MSI -Class FolderRedirectionInfo | Se ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (\\\\\\:String) [], RuntimeExcept ion + FullyQualifiedErrorId : InvalidRegularExpression So, when I get the chance, I guess I'll have to open up a Support Ticket, and see if someone at LT knows what's going on. Thanks!
  14. I know, I know - this is one of those "if you don't already know, you should probably swim back to the shallower side of the pool" things, but I figured it'd be easier to ask than to keep google searching something I keep failing to articulate. Pride be damned. I have a PowerShell script to run at logon for a user, which will pull the locations of their User Folders, and the sizes. It then stores them in a custom WMI Class/Instance. From here, I created a LabTech script to get the values of the WMI Instance properties, by name, and store them in matching EDF's I created. That's all well and good. What I'd like to be able to change (aside from how LT 11 displays EDFs), is the values that the LabTech script puts in to the EDFs. I'll show you what I mean: On my PC, if I run Get-WmiObject -Namespace root\MSI -Class FolderRedirectionInfo | Select -ExpandProperty Documents Then, the output is \\SERVER\RedirectedFolders\user\My Documents So, in my LabTech Script, I have POWERSHELL: Get-WmiObject -Namespace root\MSI -Class FolderRedirectionInfo | Slect -ExpandProperty Documents SET: [EXTRAFIELD Documents] = %powershellresult% And when I check my EDF's, the value in 'Documents' is \\\\SERVER\\RedirectedFolders\\user\\My Documents And, I get that the difference is p negligible, but LT is already giving us very limited real estate to display EDF data in the EDF Tab - so doubling up on the '\'s is just making the path that much longer/less visible at a glance. Plus, if we then want to have a script that GETS the EDF value, and use it for something - p sure it wouldn't work. Anyway, I know it's dumb and probably super simple, but I appreciate any help you guys can offer. All this burning the candle at both ends and in the middle stuff, I think, is having a sincere impact on my google-fu.
  15. Oh, weird - didn't have the double-header in my editor O_O And I didn't even copy/paste, full-on typed it out. Anywho - downloading it from the link you provided, I was able to Import it without issue. For comparison, I've attached a screenshot of the two files, side-by-side - the one on the left is the one I was working off of yesterday, and the one on the right is the one I just downloaded. *shrug* I appreciate all the help!
  • Create New...