5

At work, we're using a Windows Server 2008 R2 VM as our build server. At the end of the build process for any of our projects, we copy the packaged deployment files to a folder on the server where they'll be deployed. (This is done in a batch command by a service account.)

For most of our projects, which deploy to a Windows Server 2008 R2 VM, this step goes swimmingly. But for one project, which deploys to a Windows Server 2003 R2 VM which resides in a different domain on our network, the .zip files return "Access is denied" and don't copy, though all of the other files copy correctly.

  • Our sysadmins say they haven't prevented this in group policy or by other means.
  • If I'm logged in the build server as myself and run the copy in the command window, I can't copy the .zip files over either, so it's not just a matter of the service account's permissions.
  • If I log into the 2003 server and then copy from the build server to the 2003 server, using the command window, it works, whether I run as myself or as our service account.
  • Only .zip files cause the "Access is denied" problem. Even a (fake) .exe file copies correctly.
  • All of our other projects have .zip files, and they copy to their 2008 R2 server correctly.

Is there a way I can get the Windows Server 2003 R2 VM to accept .zip files copied from our build server?

EDIT: A couple more tests...

  • If I create an empty text file and change it to .zip, it copies correctly.
  • If I copy the files (including .zip files) from another project, the .zip files give "Access is denied".
  • I noticed that the service account doesn't have access to the main directory under which our build products go. So I gave it Full Control to that folder. Everything else worked, but the .zip files gave "Access is denied" when I did this.
Kyralessa
  • 171
  • 1
  • 7
  • Any Anti-Virus products getting in the way (thinking more along the lines of the heuristic type functions in the likes of McAfee VirusScan)? – Simon Catlin Aug 30 '12 at 21:46
  • Do zip files from other projects copy correctly to the destination server? – joeqwerty Aug 30 '12 at 21:53
  • @SimonCatlin, we use Microsoft Forefront. It *could* be getting in the way, but it's not clear why it would only happen when copying to this one server. It's running on everything. – Kyralessa Aug 30 '12 at 21:54
  • @joeqwerty, that's a great question. I tried that and a couple other things and edited in my results above. – Kyralessa Aug 30 '12 at 22:06
  • It sounds like there's a File Screen on the destination server that's blocking compressed files. the reason your renamed text file works is probably because it's not actually compressed, it just has the .zip file extension. Can you have the destination admins check for a File Screen? – joeqwerty Aug 30 '12 at 22:25
  • @joeqwerty, I have access to log onto the server (it's just a test server). How can I see whether File Screening is installed and enabled? – Kyralessa Aug 30 '12 at 22:31
  • Go to Server Manager|Expand Roles|Expand the File Services role|Expand Share and Storage Management|Expand File Server Respource Manager|Expand File Screening Management|Select the File Screens node and look for any file screens in the right pane. – joeqwerty Aug 30 '12 at 22:40
  • @joeqwerty, File Server Resource Manager isn't installed on the 2003R2 server. Does that make it safe to assume that there aren't any file screens? – Kyralessa Aug 30 '12 at 22:46
  • OK, I got confused with which server is which. I thought the destination server was W2K8 or W2K8R2. Nonetheless, you should be able to find File Resource Manager (if it's installed) in Administrative Tools. – joeqwerty Aug 30 '12 at 22:54

1 Answers1

2

Here's the solution we hit on today.

  1. Run Internet Explorer on the non-build server (the 2003 R2 server).
  2. Tools > Options
  3. Security tab
  4. Highlight Local Intranet and click Sites.
  5. Click Advanced.
  6. Uncheck the "Require server verification (https:)" box.
  7. Add our server to the list of sites, in this format: file://ourservername.ourdomainname.org.
  8. Close and save all dialogs.

This fixed the .zip file problem. After we did this, we ran the build again and it was successful, including the step that copies the .zip files.

As best we can tell, the server on the other domain wasn't recognizing our build server (and its domain) as being part of the same local network.

Kyralessa
  • 171
  • 1
  • 7
  • Were the two domains in the same forest or separate forests? If they were in separate forests this would make sense. – tsells Sep 04 '12 at 02:58