Jump to content

danialbulloch

Members
  • Content Count

    84
  • Joined

  • Last visited

  • Days Won

    11

danialbulloch last won the day on March 26

danialbulloch had the most liked content!

Community Reputation

23 Excellent

Recent Profile Visitors

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

  1. @ckochosky Try restarting the control center. It's a common problem when importing scripts that come with EDFs.
  2. Check the command history of the computer you are running it on. If you open the script and click the debug button you can step through it step by step, watching what it does, and referencing the commands on the computer to see if it does things right. While also hand verifying for things like downloading the ISO.
  3. So I never saw this post when I made my offline domain join script, but check mine out @KyleChx. It does work. Feel free to post there if you have any questions.
  4. @srogersOne issue I see with your logic is that you are setting the EDF before verifying the password. If the password fails to set properly, you are updating the EDF anyways, so the wrong password will be set. I'd recommend doing a variable check on the output of line 10 to make sure it says "Credentials Correct". Any other return should be counted as a failure, and not update the EDF. Also, check the command history of the computer you are testing on, see what the results are of both of the commands I gave.
  5. Sounds like the powershell is failing to even run. Make sure the computer has the latest version of powershell installed(PS5.1). I'm not sure what is required, but it does use a bunch of powershell, and I can see that causing a problem. You can also check the target machine's command history and see what the powershell command returned directly.
  6. @ObsidianJason There are logs of the install attempt stored in C:\tne\temp\ (unless you changed the default folder). That can be used to help debug any failures you have.
  7. If you are on hosted, you are going to have to put the file somewhere else. You can change the download line in the script to be the other download option, and update the address to have the domain on it(and possibly folders). That's what a lot of people do when they are either on hosted, or don't have a lot of bandwidth to spare on their server.
  8. On your Connectwise Automate server. Where exactly? I cannot say, that depends on your setup. If you cannot access the ltshare, you could preload it on client networks and put it on a local network share.
  9. Perhaps try restarting the CWA server? Someone else suggested it started working after that happened(they restarted it for unrelated reasons).
  10. That's odd, must mean that the script didn't create the EDF properly. Try reimporting it.
  11. 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.
  12. 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?
  13. @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.
  14. 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.
×
×
  • Create New...