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.]]

absoblogginlutely! last won the day on July 25

absoblogginlutely! had the most liked content!

Community Reputation

2 Neutral

My Information

  • Agent Count

Recent Profile Visitors

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

  1. Scarily so, yes 😞 I'm not a professional programmer but even I know that the encryption should be one way.
  2. Just a heads up to all that use this plugin that as this code has now been posted online , the encryption key that is used to encrypt the passwords into the database for all of your administrative users, is now on the internet at https://github.com/mspgeek/MSPAccounts/blob/master/Globals.vb Admittedly it's not easy to get access to SQL but with this code you can reverse engineer all of your tech's admin passwords across every domain. I guess you could say this is a good thing as you can audit your techs password complexity (and hopefully it's not a password they use elsewhere) but imo an admin can now see everyone's password with no audit log.
  3. What Marc means to ask is "Is there a plan/workaround to have the commands run via the change password option so the commands are obsfucated in the logs?"
  4. Thanks Darren - after I posted this I realised it was sending it to Connectwise based on the fact that I had to set up the sync. I can confirm it is working and updating the dates correctly. My initial run did eventually complete but there was a long time (probably around 10 minutes?) between the last id being updated on screen and the script completing. I made use of the time by hunting for the data in Automate 😉 Great job!
  5. Thanks for posting this Darren. My thoughts on the install process to make it even easier for people is as follows. For step 2 you need to extract the directories from the zip file into c:\program files\WindowsPowershellModules on the Automate server. Step 2a would be to install the file in Automate - (the last bit of line 2 is missing a return/a couple of words). Step 2.12 also has two lines running together. In Automate 12, you need to use System/General/Import/XML Expansion In my case I got a message that the script was from a newer version of Labtech (ironically enough they are not using the software name!). We are using Automate 12.0.327 Patch 5 Step 6 would be to select System/Connectwise Manage. In step 6.1 There are 3 Purchase Date fields. You only need to update the Computer one. Same for the WarrantyExpiration I've run the powershell script on the server (thats a great way to include a script to run) and it went through and updated several machines. Eventually it just seemed to stop. Not sure what it's currently doing - I suspect it's waiting for a timeout? It looks like you've hardcoded your api into the code - do we need to register for our own api so we don't run against your api limits? Finally I can't find where the information retrieved from the script shows up in Automate. I've got to be missing something obvious here! Looks like a great step and also a good pointer on creating some powershell/api intergrations for myself. Thanks for all your hardwork and willingness to share.
  6. If your users use a ! (and possibly &) the passwords will be truncated at the first ! as it's taken as a delimiter. Ie a password of password! would be sent to AD as password
  7. For those of you running the original script, we found that the manage-bde | select-string "Protection On" will give you a false positive as Labtech runs the command with quotes around it, so it actually stops after Select-string. This generates an invalid command and echoes the rest with Protection On. As the next line checks for the word On, every single computer now has TPM on according to the logic. Solved by making the text manage-bde | select-string 'Protection On' in single quotes.
  8. Update - I ran the command manually to add this user to domain1.tls at Manage Locations, selected location, selected add user and added the user successfully. I was able to add the user to all of the other locations with no problems. The locations with "nothing was logged" already seemed to have the user in existence. (but because the user existed, the domain admin membership did not take place. As a feature, it would be nice to add the user to all locations again even if the system thinks the user exists rather than doing them individually one at a time.
  9. After testing I rolled this out and found out some of my users were not created in AD. the plugin showed the user was already there, so ran the script to remove the user. Then reran to include the user. User still does not appear - Not sure why yet - the output from this user is below (domains changed) domain1.tls: Creation of user failed. cp2k.corp.cpi.domain2.net: Creation of user failed. domain3.local: User created but failed to add to Domain Admins. dom4.local: Nothing was logged. dom5.local: Creation of user failed. dom6.local: Nothing was logged. dom7.local: Nothing was logged. dom8.local: Creation of user failed. dom9.local: User created but failed to add to Domain Admins. Are there any other logs generated somewhere so i can get more details? Running ver version
  10. To fix the userlogin information, update the user creation command to include -samid %username% and the upn can be set with -upn %username%@domain.com I can see the tricky bit obtaining the domain part for the upn. ie this command sets the user account, 2000 login and the upn to different names (to show off) dsadd user "cn=adminflastname,ou=MYMSP User accounts,dc=contoso,dc=local" -fn Firstname -ln lastname -display AdminALastname -pwd P@ssword1 -email ahlastname@mymsp.com -samid adminalastname6 -upn alastname7@contoso.com The only reason I see the upn being necessary is for accounts that have dirsync enabled with Office365 - without the UPN being filled out, they won't synch up to office365 and therefore our users would not be able to administer the office365 account. Hope that helps a bit
  11. This tool is awesome...here are my first impressions but it is looking good. I deployed this to our server this morning and mysql crashed when I restarted the dbagent which unfortunately took Labtech down. Had to restart the mysql services - oops! I'm not sure why this caused mysql services to stop - I've not seen that happen before. One suggestion would be to add this forums' URL to the readme notes and also the about field in the plugin itself so users know where they downloaded the plugin from and where to go for support (assuming this forum thread is the official location?) It would be nice if we could customize the name format - we already use admin firstname last initial for our local domain admin accounts, so it would be nice to be able to change the login in this plugin to use our naming convention instead of adminfirstinitialfulllastname (although this difference made it easy for me to see if the plugin was working successfully. Edit: I noticed that User accounts are created with the Pre Windows 2000 Domain name and the User Logon name is left blank, along with the upn suffix.. Could this be changed to set the UserLogon name instead of the pre Windows 2000 version? Also the ability to change the OU that the accounts get created in - again we already have a predefined OU structure, so being able to dump the accounts in this OU would be great. Mind you, our OU is not exactly standard for example CompanyA in Labtech might be "ou=AdminAccounts,ou=Admin,ou=companyA,dc=company,dc=local" whereas companyB might be "ou=AdminAccounts,ou=Admin,ou=compB,dc=company,dc=local". That does gets slightly trickier to work around without specifiying the admin OU for each location (which is a tiresome process but I guess that is what you get if you don't standardize). Unfortunately we also have clients that don't have domains (yeah I know!) and it would be nice to have an option to say "NoDomain = local user accounts on all computers" Is there any update notification/self updating logic or do we just need to watch this thread for new updates? I'm not familiar with plugin development, but does the plugin utilize scripts in Labtech or is everything hard coded in the DLL?
  12. By removing the software on one of the computers and then checking the event logs I saw that the product code in my case was {735EF746-77A8-44E8-821F-4C77F038AA90} (Grab this from the Bytes option under Source=MsiInstaller, EventID= 11707 So it was then a quick shell of msiexec /uninstall {735EF746-77A8-44E8-821F-4C77F038AA90} /q /n /l "c:\temp\clouduninstall.txt" and one (unanticipated) automatic reboot later, Cloud was removed from the computer. However I then ended up with Symantec Endpoint protection on the machine running as a service with no user gui anywhere that I could see. fixed with another uninstall, this time with two uninstall commands and a reboot to cleanup the Symantec endpoint service:- MsiExec.exe /x{A84E6630-FE81-4D1F-BBA0-4BFBCC1D9493} /q /n /l "c:\temp\sep2uninstall.txt" /REBOOT=REALLY_SUPPRESS "C:\Program Files\Common Files\Symantec Shared\SEVINST.EXE" /U /Q Followed by a clean up of the now manual Symantec.cloud Cloud agent. sc delete ssspnav sc delete sspaadm rd /s c:\program files\symantec rd /s c:\program files\symantec.cloud That *should* be it from my testing. I have not got around to scripting all that in Labtech......yet
  13. Labtech continues to run scripts where it left off after a reboot from my experience. Also from my experience, Symantec uninstall sucks..... Trying to remove the cloud product here too and stumbled across this thread - did anyone get this solution to work within Labtech? My goal was initially to remove from Labtech so I can control and automate the whole remove old product, install new one, but I think I can just get Labtech to do a search of machines that do not have symantec cloud on them (after they are removed from the web interface) and then launch the whole reboot/install new product script.
  • Create New...