David,
In case you're still hitting up against this problem, it's actually rather simple to fix. But it's not documented ANYWHERE, and it took me ages to sort it out in my environment. Everything you've done is good, and it's what I'd call a bug in how IE gets it's WPAD info and connects to the web server.
First of all, you can't use a CNAME record for WPAD. Use an A record. Silly, I know, and it shouldn't make any difference, but it's definitely the case. So remove your CNAME in your DNS, and make an A record for the IP Address of the web server.
Secondly (and this may be more tricky for you), you need to have the WPAD.DAT file located on the root of the default website that's listening on the IP Address that you've assigned above. This is the key. It WILL NOT work with a host-header field or anything like that.
Explanation: What IE does is resolve the name WPAD to an IP Address. It's got to be able to resolve it directly to an IP Address. If it resolves as a CNAME query does to a different name, it won't work. So once IE's got the IP address that WPAD resolves to, what it actually does is connect to http://<>/WPAD.dat. If you've got a different website set up on the same webserver, listening on port 80 but using a host header field like I had (IE, "default web site", as well as "WPAD Website"), then you'll have everything set up correctly, but it won't work for that very reason. Put a copy of your WPAD.DAT file on the root of your default website, and things should start working.
Of course, if you can't get access to the root of that website (or you can't secure the root of that website), then you may need to look at moving your WPAD site to a different server where it can be at the root of the IP Address assigned to that server.
Give that a shot anyway. That's the process that worked for me. It took me ages to get it working, but it's been reliably working now for a long time. All the above though is simply my understanding of how IE works in relation to WPAD.DAT files, and might not be correct - it's simply based on the observation of what it does in my own environment. Yours may be different, but I'd put some money at least on that fixing your issue.
Let me know how you get on!
Matto :)
The simple way to do this is to create a batch script that copies the bookmarks from a network share to the user's profile. The assign the script to run at login time using GPO.
EDIT:
Sorry for the previous answer. Apparently Firefox bookmarks have been in a sqlite database since v3.
You have work to do. According to this page you can use sqlite to query the places.sqlite database and retrieve records. The Mozilla developer page is here.
The sqlite executables are available for download here:
And you can use the SQLite manager Add-on for firefox to learn the database layout so you can script the adds.
Best Answer
At our organization, because of how little it's called (even with a thousand users!), we put it on our web server, and point it there specifically, using the IP address. The reason we do this is because if the server is unavailable, it won't stop them from connecting anyways (i.e. if they take their portable computer home).
Putting it on a file share is something I haven't tried, but I don't imagine it would be difficult. Putting it on each computer is horrible because:
Because of how small the proxy.pac files are, I'd recommend just keeping them on a webserver, and pointing it there. If you use a hostname instead of an IP address to point to it, you should be able to setup another server for redundancy as well.