Jump to content

A+ Computers

Members
  • Content Count

    1,583
  • Joined

  • Last visited

  • Days Won

    205

Posts posted by A+ Computers


  1. it is saved forever until you delete the file from the backup.

     

    Unless you are using one of the advanced backup features that deletes the files out of the backup when you delete it locally, or delete it from the backup which deletes it locally...silly feature, but I'm sure it has its use case somewhere.


  2. take a look in programdata\avg online backup\csvreports\  . This contains a log of what was backed up and when.

     

     

    programdata\avg online backup\logs contains all of the log files from the program. You should take a look at the SAgent.service_VXXX log file

     

     

    have you tried simply removing cloud  care and reinstalling it on one of the machines that it is not working on? However unlikely, there is always the possibility of a corrupt installer.


  3. You can also perform this from the client software installed on your endpoint

     

    Open the backup program

    select "view/restore"

    select a folder

    If you see a drop down for the date on a file, you can select a previous version to restore.

     

    You can also select a date range from the top menu on the view/restore page to filter the view to only show items backed up between a specific time period.


  4. Generally, most business clients are going to have more then 1 machine, so this shouldn't be an issue for you. Simply restore the data from one of the other machines at the client's site.

     

    You could also just spin up a vm on one of the machines at your office and use that to install the OLB client for different customers. All you'd need is a network share to save the files to.

     

    If you have windows 8 or higher, you can simply install the hyper-v role and go from there. Windows 7 pro can install xp mode, which is at its root just a VM to do the same thing. You can also look into any of the other 3rd party virtualization platforms such as VMware player to accomplish this.


  5. You don't need to purchase another license to install OLB. Simply create an installer from that customers account, only include the OLB component and put it on whatever machine you want.

     

    OLB is licensed by the number of 25GB buckets you purchase, not the number of machines you install it on. You can have 100 machines all using the same OLB storage space if you wanted, or 1000, it doesn't matter. Just as long as you purchase enough space to hold all the stuff you are backing up you are good to go.

     

    Also, if you are looking for a complete disaster recovery plan, you may want to look into the shadowprotect offering. It will give you the ability to do bare metal restores, not just file level restores.


  6. if memory serves, you cannot restore files over 500MB from the portal, you have to do it from the OLB software installed on an endpoint.

     

    You can use any machine with OLB installed from the same customer account to access the backups for other machines for that customer. Simply select the device name you want to connect to when logging into the end point software.


  7. it could simply be that there is still backup data left on the AVG servers for that device, so even though it has been uninstalled, it is still expecting the device to adhere to the last backup policy it had.

     

    Go to your devices screen under that client account and use the view dropdown to change it to "uninstalled devices with backup data". If you still see the device listed and using space, flush out the data and see if it still alerts you after that.


  8. We are getting closer to nailing down the issue we are experiencing with the CC service module in MW. It may simply be that we have too many devices in our main portal and the service module in MW is timing out pulling the info it needs.

     

    I highly suggest you test the CC service module if you are demoing MW to ensure you do not run into the same issue. We have over 1200 devices in our main portal. Our secondary portal has around 40 and works just fine.


  9. Well, we finally grew our managed client pool enough that the minimum monthly bill was the same as we would be paying on a pay as you go model.

     

    As ProLogic pointed out, you have to put the time into configuring it or you are going to go crazy. Its been a few months since we started using it and I still find myself tweaking things on a weekly basis. its usually just small things, such as enabling self healing on an alert so that the alert goes away if MW was able to successfully correct the error condition through an automated script or the condition clears itself (such as toner being added to a printer).

     

    We have already started saving a lot of man hours by being able to script many of our maintenance tasks and through the built in scripts that run when alerts are generated. The remote tools are good, although the built in remote desktop tool is just simply functional (unlike remote IT). it does have the ability to connect through several different methods though, including remote assistance, vnc, ultra vnc, telnet, putty and web console.

     

    Support for MW has been top shelf so far. Emails are answered the same day they are submitted and the staff answering are knowledgeable on the product. 

     

    I have been having an issue with the AVG CC service module, but that is due to an issue on the CC back end, not MW. I can say that with confidence as we manage two portals and while one of them works properly in MW, the other does not. This issue has been ongoing since we signed up a few months ago and I have been in contact with MW/CC support multiple times.

     

    My one big complaint is that some features do not function properly in chrome, so I am forced to use IE now and then. Its really just an annoyance though as i prefer chrome.

     

    If you are looking for a RMM solution, I highly recommend giving MW a test drive. We got a 30 day trial before we signed up and AVG graciously extended that trial for me so that i could finish testing some things.


  10. You shouldn't get an error when trying to open the software. That password is set in the portal, it is not the domain or local admin password and should have nothing to do with any changes made to those accounts..

     

    When you set a backup to run even when no user is logged in, that is where you give it a local or domain login that would be affected by a password change.

     

    The error you are getting sounds more like a SQL error message. 


  11. Just came back to say that I tried installing MW again, saw the trusted hosts string come back and once again could not backup exchange. Removed the string, restarted the winRM service and exchange backup once again works. 

     

    So for me at least, this issues is directly caused by managed workplace.


  12. Its funny you should mention that it was working before you updated it last week. The last time I logged onto this server was a few weeks ago to restart the exchange vss writer and it was running an older version of the OLB client. When it started having issues, I noticed that it is running the current OLB client. 

     

    Its in a policy group that has component updates turned off and I don't recall sending an upgrade command to it through the portal....


  13. So I ran into a strange issue at a site that was previously backing up the exchange database on a sbs2011 server with no issues. I can't say for certain what the cause of the issue was, but I can share what I did to fix it with you all.

     

    The machine in question had been backing up exchange without fail for the past year, until this Saturday. On Monday when I got to the office, I had alerts that it had failed its backup on Saturday and Sunday. Wanting to get on top of things, I remotely connected to the computer to manually run the backup to see what the error message was. Upon running the exchange backup, it failed with the message: 

    "remote connection to exchange powershell failed. the winrm client cannot process the request. the winrm client tried to use negotiate authentication mechanism".

    Checking the log file, I found the following:

     2015-06-22 13:55:49,916 [75] ERROR   ExchangeDatabaseHelper - Remote connection to exchange powershell failedSystem.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Negotiate authentication mechanism, but the destination computer (servername.domainname.local:80) returned an 'access denied' error. Change the configuration to allow Negotiate authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.
       at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
       at System.Management.Automation.Runspaces.RunspacePool.Open()
       at System.Management.Automation.RemoteRunspace.Open()
       at SOSOnlineBackup.Client.Library.Core.ServerBackup.Exchange.ExchangeDatabaseHelper.#=qAfHJDyVlNUIbtMF901ydZDQuGYtnf29RrHqQ_Pc$nTg=(String #=qRdqAFHDx4uMVXp8PR1o9Rw==, String #=q1TheYha1Di_w5bQQZYI1Fg==)
       at SOSOnlineBackup.Client.Library.Core.ServerBackup.Exchange.ExchangeDatabaseHelper.SetActualBackupDates(IEnumerable`1 exchangeDatabases)

    The only thing that had been changed on this server between the time the backup was working on Friday night and when the backup started failing on Saturday night was that we deployed Managed workplace Onsite manager software on the server. Now I don't fully believe that this was the cause as i should have seen the Friday night backup fail as well, but I had to start there. After removing the onsite manager software and restarting all relevant services (AVG online backup service and windows remote management service) and trying the backup again, there was no change. No change even after a system reboot.

     

    Onto google. I found this post which got me to check the registry. I found it strange that the registry dword mentioned in the post wasn't there, so I logged into a working sbs211 machine and checked its registry. I found that it too did not have the auth_kerberos and auth_negotiate keys, but instead it had auth_basic, which the failing server did not have. In its place on the failing server was instead a string named trusted_hosts with "*" as the value.

     

    After backing up the registry key, I removed the trusted_hosts string and added the auth_basic dword back, set the value as 1 and restarted the services. 

     

    I am now able to backup exchange once again without receiving an error. 


  14. Hi Adam

     

    We looked into this when OLB was announced and while it is possible, we decided that setting up a single account to share between all of our clients was a really bad idea. 

     

    When you setup an account with OLB, you need to create a password in order to access backups and restores through the client software. With a single account, that password is the same for all of your customers. Since you can access the backup data for any computer on the same account from any end point, this opens up the possibility of people restoring or deleting other customers data.

     

    It also makes management of the service a nightmare. With individual accounts, you can see when a customer needs to purchase more space quickly and easily. If you have everyone under a single account, you will have a more difficult time determining who needs to pay more for the space they are using.

     

    You will also run into renewal issues for the other services. The AV and CF services on an account share the same renewal date, regardless of purchase date.  So if you sell AV to someone on Jan 1st, and then you sell AV to someone on Dec 1, the second license will only have a month before it expires and needs to be renewed. It is important to note that AVG does not charge you full price for licenses purchased after the renewal date. So if you don't want to deal with the accounting headache of figuring out how much you need to bill the customer, then keep all the customer accounts separate.

     

    lastly, there is the issue of giving customers access to the portal. You have the ability to setup user accounts to give customers access to their own portals. These accounts can see anything under their client account, but not other client accounts. By placing all the machines in the same client account, you won't be able to give anyone access to the client account as they will be able to see all of the other customer devices and make changes to them. This will also give them the ability to see other peoples backup data and restore it to their own computers.


  15. if you can hit it quick enough, un-check the close when completed box on the OLB window. You can then scroll down through the basic log view ans maybe get an idea as to why it failed.

     

    If you just can't get to it quick enough, you can check out the full log files located at \ProgramData\AVG Online Backup\Logs

     

    Also, which backup is it that is failing? File/folders, exchange or SQL?

×
×
  • Create New...