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

danialbulloch last won the day on December 24 2019

danialbulloch had the most liked content!

Community Reputation

16 Good

Recent Profile Visitors

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

  1. Perhaps try restarting the CWA server? Someone else suggested it started working after that happened(they restarted it for unrelated reasons).
  2. That's odd, must mean that the script didn't create the EDF properly. Try reimporting it.
  3. Yup. That one is common. Just reload system cache on your Control Center, or close it and reopen it. Basically when you import it, CWA server creates the EDF that stores the network path, but your client doesn't know about it yet, so it makes that error. Reloading system cache or restarting the Control Center makes it check that again.
  4. I'm not sure. I've never seen that before. It is possible there is a problem with the harddrive, since it is failing at the data migration stage. Perhaps some data it cannot read?
  5. @lsquez and @plinley, that actually happens because you imported the script, but didn't reload your system cache afterwards. So the server knows about the EDF, but your Control Center client did not. You can reload the system cache by clicking the user icon in the top right, or I believe pressing ctrl+r. Or, if you want to go overboard, restart your Control Center completely.
  6. Oh, it could have been that you needed to do a Reload System Cache. Basically your computer didn't know about the EDF, but the server did. Restarting the server caused you to restart your client which forced a cache reload.
  7. What does your line 17 look like? That's an EDF reference, so if the EDF didn't import properly, I could see how it would cause problems.
  8. Line 31 would need to be modified. Instead of being "File Download" it needs to be "File Download URL".
  9. Nevermind on my request. Someone pointed out the TLS setting, which is in a newer version than I originally had installed. Doesn't seem to be helping yet, but I'm going to do more testing before asking for help again.
  10. I use a script to schedule a report automatically, but I'm not sure about a one off report. Basically what I did was turn on SQLSpy, then schedule a report, and look at all the SQL commands. It's quite complicated, but in the end you should only need to run two SQL commands. One to create the schedule, and another to add the report to the schedule. The problem would be scheduling I assume. But if you could schedule it to run once, then have a nightly script(or a script that was automatically scheduled during the run of the first script) to delete the scheduled script after the first scheduled run.
  11. @Farhan Khalid Thanks for the suggestion. You are right, I didn't do a good job of directing users where to change that. It's a location based EDF. If you double click on a location(not a client), then go to the Info tab, then TNE Setup, there's an EDF there to be updated.
  12. My script isn't safe for public consumption, but most of the heavy lifting is done by Powershell. Here are the two important parts of it. Part One, creating or updating the user. $Password = ConvertTo-SecureString -string '@Password@' -AsPlainText -Force $Username = '@Username@' Try{$User = Get-LocalUser -Name $Username -ErrorAction Stop; write-host "User exists"} Catch {write-host "User does not exist"} if(!$User) { Try{$UserCreation = New-LocalUser -Name $Username -Description "MSP Local Administrator Account" -Password $password -ErrorAction Stop; $User = Get-LocalUser -Name $Username -ErrorAction Stop} Catch {write-host "User Creation Failed: $_.Exception.Message"} } if($User) { Try{$GroupAddResults = Add-LocalGroupMember -name Administrators -Member $User -ErrorAction Stop; Write-Host "User added to group"} Catch {Write-Host "User Already in Admin Group"} Set-LocalUser $User -PasswordNeverExpires $true Add-Type -assemblyname system.DirectoryServices.accountmanagement $DS = New-Object System.DirectoryServices.AccountManagement.PrincipalContext([System.DirectoryServices.AccountManagement.ContextType]::Machine) if($DS.ValidateCredentials($Username, '@Password@')) { Write-Host "Credentials do not need to be updated" } else { Try {$UserUpdate = Set-LocalUser $User -Password $Password -ErrorAction Stop; Write-Host "Credentials Updated"} Catch {Write-Host "Updating of credentials failed"} } } Part Two, verifying the credentials are correct. Add-Type -assemblyname system.DirectoryServices.accountmanagement $DS = New-Object System.DirectoryServices.AccountManagement.PrincipalContext([System.DirectoryServices.AccountManagement.ContextType]::Machine) if($DS.ValidateCredentials('@Username@', '@Password@')) { Write-Host "Credentials Correct" } else { Write-Host "Credentials Incorrect" } I use machine level EDFs to store the password after I've verified it to be correct. The first script also verifies the credentials, but for safety I verify a second time with a new powershell session so I can be 100% sure the password was updated. At the beginning of the script I check to make sure the role of AD Domain Controller isn't present, so that we don't accidentally end up creating the domain user, and then changing the password for every domain controller on a network.
  13. We also rerun the script daily, meaning that the admin password for each computer rotates daily as well. This gives us the advantage of, in a pinch, being able to give the client the password knowing it wont be any good tomorrow, even if they write it on a sticky note and tape it to their screen. If you do that, just make sure you verify it has been changed before updating the EDF.
  14. CWA scripting actually has a generate password function. I use that function to generate the password, then use commands to set it and write it to a machine level EDF. That way every single machine has a unique admin password. That's important because if you use the same password for every computer in a client, if one machine is compromised it's pretty easy to brute force even complex passwords on Windows user accounts. Which means compromising one computer could be a very easy gateway to compromising all computers in a network automatically and invisible to the user.
×
×
  • Create New...