Snap Deploy 3 - Writing to a share

Discussion in 'Other Acronis Products' started by ksr0108, May 22, 2008.

Thread Status:
Not open for further replies.
  1. ksr0108

    ksr0108 Registered Member

    Joined:
    May 22, 2008
    Posts:
    5
    Location:
    The Netherlands
    When I install Snap Deploy 3 (Workstation Ed.) on a Windows 2003 Server without any AD connection. A workstation can write a image (offline imaging with PXE boot) to a share on the Windows 2003 Server.

    But when I install Snap Deploy 3 on a Windows 2003 with AD connection. A workstation cannot write a image (offline imaging with PXE boot) to any share with any permissions.

    Just the same failure: The file name, location or formate "\\server\images\filename.tib" is not valid.
    Please type the file name or location in the correct format.

    Does anyone have a solution for this issue or is this a one of a kind bug from Snap Deploy 3?

    Regards
    Richard
     
    Last edited: May 22, 2008
  2. ksr0108

    ksr0108 Registered Member

    Joined:
    May 22, 2008
    Posts:
    5
    Location:
    The Netherlands
    I think it's something with the security authentication. When I connect with the share it ask my username and password, but after the connection, I can't write in the share.

    But when I enable the Guest account, there is no problem at all. So the security authentication get lost.

    You can read the fix from Acronis below:
    disable "Digitally sign communications" in Security settings-> Local policies->Security options
     
    Last edited: Jun 5, 2008
  3. MTFysherman

    MTFysherman Registered Member

    Joined:
    Apr 28, 2008
    Posts:
    8
    Thank you God I am not the only one. I have this same problem and have spent several hours working with Acronis in trying to solve this. I still have not received a solution yet. Sorry no solution but you are not alone!!! BTW it is not a rights issue. I had mine clean and I had Acronis double check them. Something else is going on. Will post if I ever receive a solution but it has been over 3 weeks trying to solve this.
    Good luck!
     
  4. MTFysherman

    MTFysherman Registered Member

    Joined:
    Apr 28, 2008
    Posts:
    8
    I tried the solution above and it doesn't seem to solve the problem. Interesting that I have been working with Acronis and have had them remote into my machine but they NEVER told me about this as a solution.
     
  5. MTFysherman

    MTFysherman Registered Member

    Joined:
    Apr 28, 2008
    Posts:
    8
    There are a few digitally sign communications settings in the local policy. Could someone give me the full syntax, maybe I have the wrong one disabled. I have two for Microsoft Network Client and two for Microsoft Network Server each has a Digitally sign always and a Digitally sign if server agrees. All four are disabled though
     
  6. ksr0108

    ksr0108 Registered Member

    Joined:
    May 22, 2008
    Posts:
    5
    Location:
    The Netherlands
    It works for me, when i disable:

    • Microsoft network client: Digitally sign communications (always)
    • Microsoft network client: Digitally sign communications (if server agrees)
    • Microsoft network server: Digitally sign communications (always)
    • Microsoft network server: Digitally sign communications (if server agrees)

    Have you reboot the server after changing the configuration? Mostly the command gpupdate also works.
     
  7. eswann_GL

    eswann_GL Registered Member

    Joined:
    Jun 30, 2008
    Posts:
    5
    I had a similar issue. Solution was to use the credentials of the local admin account of the server you're trying to connect to. Completely contrived, I know, but SD 3.0 won't pass along AD credentials. To say I'm extremely disappointed with the complications by upgrading from SD 2.0 to SD 3.0 would be an understatement.

    Ed
     
Thread Status:
Not open for further replies.