Advice on backing up IIS

[Hagfish]

Can anyone point out some good links and / or help me out with some advice on backing up an IIS FTP server? The server has been flaky lately, and I can't imagine recreating all of the user permissions and directories if the server were to finally crash.. What would you do? TIA

--hag

 

[Digitalcandy]

I'd backup the system and meta state.

 

[Hagfish]

does backing up the metabase basically just get me all of the user and directory permissions? Then I would still have to back up the actual data and directories?

 

[zoeythecat]

Tons of good articles here you can look at.

http://www.google.com/search?hl=en&q=backing+up+IIS

 

[Hagfish]

I've tried metabase explorer and backed up the entire "LM" key and tried to restore it to a different server.. None of the folder permissions or anything transferred over, in fact it really didn't appear to do anything at all.. Has anyone successfully backed up and restored an IIS 6 configuration? I need all of the folder and user permissions to stay in tact.. TIA!

 

[Hagfish]

Update.. it actually did import the ftp site to the new machine, but none of the directory or user permissions.. what am I missing?

 

[bofhrevenge2]

I'm not certain about the IIS5 permissions but some of the directory permissions that IIS sets are actually just NTFS permissions, using windows back up will save this information and you can then redirect it to another location with permissions intact.
This along with the metabase should get you there, give it a try.

"Horsey to king bish three

 

[Hagfish]

I tried this.. I actually copied the entire 'ftproot' folder over to the new server, but the new server just gave all the folders default permissions, admin, system, users, etc.. I want only the admin and a the specific user to have access to the folder like it was on my old one? Surely I don't have to go through and reset permissions on a thousand folders to I?

 

[bofhrevenge2]

You will have to specify that the backup software should restore security permissions as well, i think Windows backup supports this. I use Arcserv and that certainly does.
If you just copy files to a new volume or server then the files will inherit the properties of the destination folder, backup software should apply the same permissions as what was backed up.

"Horsey to king bish three

 

[Hagfish]

Still trying to figure this out.. I used your advice and made a windows backup of the ftproot directory.. This did save the permissions as you suggested, but the exact permissions including the computername.. i.e.. it was looking for the account of "testpc\test user" therefore on the backup IIS machine the accounts showed up as ??????? questions marks.. Is there any way around this or do I have to name the backup IIS machine the same name of the one that was backed up?

 

[bofhrevenge2]

Hmm yes i can see your problem, the users would have to be the same on the other server. Can the new server not be the same name? I'm not an IIS expert i'm afraid it was just a suggestion of how you could keep the permissions. If you we're using AD users then i don't think you would have that problem.

"Sometimes, a cigar is just a cigar." - Sigmund Freud

 

[Hagfish]

That's what I thought too.. so I added that backup machine to my test domain.. Now that I've done that the domain users show up in the security tab without question marks, but I still can't log them into the new ftp. It's looking like IIS ftp only supports local machine users.. sucks!

 

[bofhrevenge2]

It might be an idea to put a post in the IIS forum forum41

"Sometimes, a cigar is just a cigar." - Sigmund Freud

 

[JimWells]

Hagfish,

To log on to FTP in IIS, the user accounts will need the "Log on Locally" permission, set in Local Security Policy.

As to your original question -- the Metabase backup will ONLY backup the settings visible in the IIS Manager snap-in. None of the actual content/NTFS permissions/etc. will be backed up this way.

If an entire folder structure needs permissions set for anonymous access from the internet, and you've moved the content to a new server, set a new NTFS permission for the IUSR_MACHINE_NAME on the folders/files, and be sure that the anonymous access settings in IIS Manager are correct and set to allow IIS to control the IUSR_ password.

Hope this helps...

 

[Hagfish]

I created a group called ftp users on the domain controller. I then went to the backup ftp server (which is logged on to the domain) and in the local security policy I allowed "log on locally" for "ftp users".. still not working

 

[JimWells]

Hagfish,

What errors are you seeing? Any log entries for the connection attempts?

Please paste samples of either into a post...

 

[Hagfish]

It keeps coming back and prompting me for a password and it won't let me login. If you are talking about the log kept in c:\WINDOWS\system32\LogFiles it doesn't say much.. it only shows

18:44:03 10.0.1.x [1]USER test 331 0
18:44:03 10.0.1.x [1]PASS - 530 1326

 

[JimWells]

1)Also check for "Access this computer from the network" in Local Security Policy (I assume since you can edit this, the FTP server is NOT a domain controller).

2)Are you putting the username format in as "DOMAIN\username", since the accounts are domain accounts?


You might also try adding a test USER account and giving it the log on locally/access from network rights, just for troubleshooting...

 

[Hagfish]

well I tried domain\username and it worked. then I got curious and took away the "log on locally" from the local policy and it still worked.. Is there any other way around this. if the ftp goes down and I have to move to the backup one, I can't have the hundreds of users logging into the ftp change their usernames and passwords to domain\username. Thanks for your help on this, I really appreciate it.

 

[JimWells]

Hagfish,

In addition to being the simplest answer to the questions already answered, this KB Article describes how to do exactly what you need, if you read down to the bottom.

Never tried it before, so YMMV.

http://support.microsoft.com/default.aspx?scid=kb;en-us;200475