I am using Vista SP1 64 bit. When I create a two way synchronization job it cannot find the mapped drive which in this case is M. It is mapped to a Dlink DNS-323. I did not have an issue with the sync job with my older XP SP3 32 bit. I have to always map the drive when I create the job. However when I do a preview of the job it says: AISBackup cannot verify that the destination drive is correct. I click change to re-select the destination and it then shows the drives mapped as Z: even though on my computer it is still mapped as M:. Also the job does not run as scheduled...not sure if it is because of that issue mentioned above or not. I have it set to log everything but there really isn't much information.
Update 1/13/09: In addition to the mapping issue I can not get a task scheduled properly. It would place something in the Task Scheduler but it would only show "AISBACKUP-" and not the associated job "AISBACKUP-M Drive Sync" so the task would run but not run the M Drive Sync.
Vista Synchronization Job Issue
Problems with Vista Synchronize
I have run some tests on Vista64 and I am sure this is the wonderful way in which Vista works with UAC.
When a job is running as an administrator, the user account is administrator, when running not in administrator the user account is your own.
If a drive is mapped in your account it is not available when running as an administrator and vice versa.
AISBackup always creates a job as an administrator when the NTFS security settings are selected and in copy / synchronise jobs this settings can only be changed when the job is set-up (we should change this to allow the copy NTFS setting to be changed via Manage Backup)
As you appear to be copying the files to a Linux NAS the NTFS security and alternate data streams would not be copies in any case – so a non-NTFS and non-Administrator job is appropriate. If you set-up a new job (based on the existing copy job) and allow select the destination share when AISBackup is not running as an administrator then everything should be okay.
Except……………….. AISBackup can only set-up schedules when running as an administrator, and makes the schedules run with the highest privilege, and – and this is a big AND, AISBackup does not schedule copy jobs correctly in any case. I am pretty sure AISBackup will still need to set-up the job using administrator mode, however it will be updated to apply the job name for copy jobs and remove the ‘run at highest privilege’ mode when the job does not require this mode i.e. AISBackup was not running as an administrator when the job was created.
Another problem I found is the e-mail log option does not seem to work with copy jobs – this will be corrected too.
All in all, a lot of corrections for a program that is supposed to be perfect.
Barry
PS sorry for the delay answering
PPS you could try setting the schedule up manually (rather than wait for the update) - we put AISBackup jobs under the task scheduler folder Aquarius IS Consultancy\AISBackup to keep things tidy.
When a job is running as an administrator, the user account is administrator, when running not in administrator the user account is your own.
If a drive is mapped in your account it is not available when running as an administrator and vice versa.
AISBackup always creates a job as an administrator when the NTFS security settings are selected and in copy / synchronise jobs this settings can only be changed when the job is set-up (we should change this to allow the copy NTFS setting to be changed via Manage Backup)
As you appear to be copying the files to a Linux NAS the NTFS security and alternate data streams would not be copies in any case – so a non-NTFS and non-Administrator job is appropriate. If you set-up a new job (based on the existing copy job) and allow select the destination share when AISBackup is not running as an administrator then everything should be okay.
Except……………….. AISBackup can only set-up schedules when running as an administrator, and makes the schedules run with the highest privilege, and – and this is a big AND, AISBackup does not schedule copy jobs correctly in any case. I am pretty sure AISBackup will still need to set-up the job using administrator mode, however it will be updated to apply the job name for copy jobs and remove the ‘run at highest privilege’ mode when the job does not require this mode i.e. AISBackup was not running as an administrator when the job was created.
Another problem I found is the e-mail log option does not seem to work with copy jobs – this will be corrected too.
All in all, a lot of corrections for a program that is supposed to be perfect.
Barry
PS sorry for the delay answering
PPS you could try setting the schedule up manually (rather than wait for the update) - we put AISBackup jobs under the task scheduler folder Aquarius IS Consultancy\AISBackup to keep things tidy.
Schedule
I have found that in Vista if AISBackup s already running as an administrator the schedule is set-up okay, if the AISBackup is elevated to administrator the schedule loses the job name.
For non-administrator jobs the Run at highest privilege must be de-selected.
Barry
For non-administrator jobs the Run at highest privilege must be de-selected.
Barry
I will take a look at this and see if I can get it to work. I had deselected NTFS settings since I was synching to the Linux NAS but I am not too sure on the administrator settings. Will I be able to backup non-system open files running as a non-administrator (provided AISFAM is installed of course)?
Sync with NAS
I did not test with opened exclusive files, but AFAIK AISFAM works in non-admin mode.
I have uploaded a version with the faults mentioned yesterday fixed:
http://www.aiscl.co.uk/build335/aisbi335.exe
This version also works with Windows 7
Barry
I have uploaded a version with the faults mentioned yesterday fixed:
http://www.aiscl.co.uk/build335/aisbi335.exe
This version also works with Windows 7
Barry
I installed the new build but it still seems quite difficult to setup a simple sync job. I tried both as an administrator and as a non-administrator. I finally had success as a non-administrator but had to monkey with it quite a bit to get it to "see" the mapped M drive. Then I had to create the task manually to run the job automatically but first I had to create one with admin rights so I could determine the AISBackup setup. Seems like needs some work. I am fairly technical and find this quite frustrating...can only imagine the frustration with someone non-technical. I was using Allway Sync before getting this reconfigured to work again. It was easy to setup and schedule. However, the main disadvantage of this product is that it won't sync any open files. I have used AISBackup for a number of years and all in all have been extremely happy with it!
UPDATE #1:
The M Drive Sync (non-administrator) task ran last night as scheduled at 11 pm however it didn't sync because it couldn't find the M: drive. "Destination Drive: M: cannot be found" is the logged message. The M: drive is mapped and I can access the files.
UPDATE #2:
Error message logged for automatic sync job
12:00:02 PM SSTART Backup Session 1 Auto Run: Started on Saturday, January 24, 2009 at 12:00:02 PM Version: 2.7 (335)
12:00:02 PM INF Platform: Microsoft Windows Vista Home Premium Edition, 64-bit Home Edition Service Pack 1 (Build 6001)
12:00:02 PM INF Run Time Parameters: [CYYYYYYY]
12:00:02 PM INF User Account: mmmjam
12:00:02 PM INF Running un-attended (non-interactively)
12:00:02 PM INF Creating Session: 1
12:00:02 PM EXCEPTION Exception: EFCreateError: Cannot create file .xml
12:00:02 PM EXCEPTION Component: fAquariusBackup
12:00:02 PM SESSEND AISBackup Session Finished: Saturday, January 24, 2009 12:00:02 PM
UPDATE #3:
Error message trying to run manual sync job even though I can get to the M: drive and also to the UNC \\dlinkstorage\volume_1 via the run command
6:58:35 PM SSTART Disk to Disk both way synchronize new and updated files with Started on: Saturday, January 24, 2009 at 6:58:35 PM 2.7 (335)
6:58:35 PM INF Platform: Microsoft Windows Vista Home Premium Edition, 64-bit Home Edition Service Pack 1 (Build 6001)
6:58:35 PM ERR The destination: \\DLINKSTORAGE\Volume_1\
could not be found.
Copy Aborted.
UPDATE 4:
Discovered new Vista 64 bit computer was not in the same workgroup as the Dlink 323 NAS and other devices on the network. Changed the Vista 64 bit to match the workgroup of the other devices and it seems to have resolved both issues for finding the M: drive and allowing a task to be scheduled.
UPDATE #1:
The M Drive Sync (non-administrator) task ran last night as scheduled at 11 pm however it didn't sync because it couldn't find the M: drive. "Destination Drive: M: cannot be found" is the logged message. The M: drive is mapped and I can access the files.
UPDATE #2:
Error message logged for automatic sync job
12:00:02 PM SSTART Backup Session 1 Auto Run: Started on Saturday, January 24, 2009 at 12:00:02 PM Version: 2.7 (335)
12:00:02 PM INF Platform: Microsoft Windows Vista Home Premium Edition, 64-bit Home Edition Service Pack 1 (Build 6001)
12:00:02 PM INF Run Time Parameters: [CYYYYYYY]
12:00:02 PM INF User Account: mmmjam
12:00:02 PM INF Running un-attended (non-interactively)
12:00:02 PM INF Creating Session: 1
12:00:02 PM EXCEPTION Exception: EFCreateError: Cannot create file .xml
12:00:02 PM EXCEPTION Component: fAquariusBackup
12:00:02 PM SESSEND AISBackup Session Finished: Saturday, January 24, 2009 12:00:02 PM
UPDATE #3:
Error message trying to run manual sync job even though I can get to the M: drive and also to the UNC \\dlinkstorage\volume_1 via the run command
6:58:35 PM SSTART Disk to Disk both way synchronize new and updated files with Started on: Saturday, January 24, 2009 at 6:58:35 PM 2.7 (335)
6:58:35 PM INF Platform: Microsoft Windows Vista Home Premium Edition, 64-bit Home Edition Service Pack 1 (Build 6001)
6:58:35 PM ERR The destination: \\DLINKSTORAGE\Volume_1\
could not be found.
Copy Aborted.
UPDATE 4:
Discovered new Vista 64 bit computer was not in the same workgroup as the Dlink 323 NAS and other devices on the network. Changed the Vista 64 bit to match the workgroup of the other devices and it seems to have resolved both issues for finding the M: drive and allowing a task to be scheduled.