mmthomas

Here are the requirements for Server 2008R2. The requirements for not-R2 are less and probably compatible with your P4. I've used workstation hardware before in order to have a backup domain controller when another server could not be afforded. The main things to think about are: 1) Drivers. Workstations often have hardware that don't have server software compatible drivers. This can cause problems anywhere from "I can't use the USB ports" to "I can't install the OS on this machine." 2) Reliability. Servers are expensive because they need to be reliable and have better performance than a workstation PC. If I had to run a domain on PC hardware, I'd be sure to have a second PC already online as a second DC replicating the AD traffic and holding the backups from the main DC.

When you share a folder, there are two permissions to think about. First are the Share permissions (the permissions set on the folder when you right-click and share it). Second are the NTFS permissions (the Security tab permissions on files and folders). In Server 2008, when you Share a folder, the default permissions added to the share when you create it are to give Administrators Owner permissions and Everyone Read permissions. The Share permissions set the absolute limit of permissions a user can have when they access a folder through the share. So with the default Share permissions, if I make a folder called Greg beneath the Users folder and give the account GregG full access to folder Greg, Greg will only have Read permissions because he is limited through the Everyone - Read permission at the share level. What many people do is give Everyone Full Control permissions at the share level, and then use the NTFS permissions on the folders to limit access. If you want to be a little more secure, you can remove the Everyone group and add the Authenticated Users group instead and give it Full Control permission on the share. You can change these permissions by right clicking on the shared folder and choosing Properties > Sharing tab > Advanced Sharing > Permissions. So, I would check that permission first. Then, if you don't want users to have access to the top level Users folder, you can assign Authenticated Users only "List folder contents" permissions and give Admins full control on it. Then on the subfolders, you will turn off inherited permissions and give each user account full control of their own folder.

Did you give your users enough permissions on the Share? Remember that you have to give them as much access on the Share level as you are going to give them NTFS permissions at any level beneath the share.

Do you have a group policy applied for automatic updates?

The way this should work is that the DHCP should only give addresses from the scope that matches the IP address on the server's NIC where the request arrived. So, if the server has two NICS and one's address is 192.168.1.2 mask 255.255.255.128 and the other is 192.168.1.130 mask 255.255.255.128 and a request comes in on the on the 192.168.1.2 NIC, then that request should be given an address from the first scope that you described. Do you have your masks set up properly on your NICs? In this same example, if you have a mask of 255.255.255.0 instead of 255.255.255.0 on the DHCP server's NICS, it won't be able to tell that there are two different networks.

Group policy is not very good for updating non-Microsoft products. In my experience, if people use group policy at all for this kind of update, they are running scripts that they have made with other third party products like AppDeploy or WinInstall or other patch/client management software. Adobe products in particular don't play nicely. People have been complaining about Firefox's lack of group policy support for a while now (there is a company that makes it's own version of firefox with group policy controls).

You only have one domain controller? If possible, I'd create a second domain controller, transfer roles to it, and then uninstall AD from the first server, remove it from the domain, wipe it, reinstall windows and then promote it again, transfer roles back, and then uninstall AD from the temporary server. I consider this easier than restoring from a backup. The temp server can be an extra workstation you have lying around. Microsoft's preferred recovery of a domain controller is a complete restore. They do not support system state recovery after a new installation of Windows Server 2008; See the last entry in the introduction section ofthis KB article.

So, you're saying that you have two domains with the exact same name "domaina.nl" which don't talk to each other at all? I'm confused by your setup, but my first instinct is that you would need to set up an alias/forwarder on your local virtual domain for email2@domaina.nl that forwards to email2@remoteservername.domaina.nl. Which means that on your other remote mail server, user email2 will need to have both addresses associated with his/her mailbox. But I'm making a lot of assumptions about your setup which could be wrong.

rsop.msc is your friend and/or gpresult.exe. These help you troubleshoot policies and see what is applying and what isn't and sometimes they will even tell you why. Also check the event logs on both the clients and on the servers where the drives should be mapping. If there is a permissions problem, it will probably show up there.

I forgot your third. In group policy, same as above except under Security rather than Connection, then Security Zones and Content Ratings. Click button to "Import the current security zones and privacy settings" and then modify setting. In the modify settings, you can modify the security for Internet or Local Intranet to disable file downloads or what not. But if you enable this, you'll need to make sure that you've got all the other settings that end users may need to run what they need to on the internet, because that is going to push out everything configured, not just your download setting. Again, downloads can be controlled through proxy software as well. Also, if you are denying all internet access, you don't need to also deny downloads.

If you really want to deny all internet access, this is better done at your firewall than in your group policy. Probably the best you can do in group policy is set one up to mandate a fake proxy for internet access. However I'm not sure if it will allow access to only one internal IP address. In your group policy, go to User Config > Policies > Windows Settings > Internet Explorer Maintenance > Connection > Proxy Settings. Enable proxy settings. Put in a non-existent address for your proxy. In the exceptions, put in your one IP-address. Uncheck "Do not use proxy server for local (intranet) addresses". I don't guarantee that that will work, though, as I haven't tried it myself. You may end up needing to implement some kind of web proxy. On the upside, your current firewall may come with a proxy option already.

Hi, Yekini, While the question you have relates to inter-site replication, it is really a routing question. Your default gateways at all of your sites need to have a route to get to the other sites. For example, let's say that in Japan the default gateway is 192.168.10.1. If that is your firewall, it may also have the WAN connection plugged in directly or it may be an end point for a site-to-site VPN. If you use a firewall-to-firewall VPN, you will usually configure it so that it knows what network is at the opposite end, e.g. 10.10.10.0. In that case, when a DC in Japan wants to replicate to a DC in NY, it sends the packets to the default gateway. The gateway knows that the VPN is used to get traffic to the 10.10.10.0 network, and the packet goes merrily on its way. With a WAN link, you will probably need to enter a static route in your gateway and/or firewall devices, so that they know that if they receive a packet addressed to the 10.10.10.0 network, they need to send it to the WAN interface address. So, Active Directory doesn't care if you use a WAN connection, site-to-site VPN, dedicated dialup, etc. It is all handled in the routing of your other network devices (routers, firewalls, etc.) I hope that makes sense. Matt

This link talks about managing printers through group policy, which is what it sound like you want to do. Your clients much be Vista or Win7 for this to work, though at the end it does talk about a workaround for that.

Mostly your teacher is right. There isn't much that is "brand new" in Server 2008. There are a lot of improvements and a lot of minor changes which some might consider big changes. But for everything that is going to be covered in one class, there isn't much difference. Sure you can run Server Core with 2008, but it's unlikely that would be covered in a class anyway. Additionally, the population of 2003 Servers is much greater than that of 2008 servers and is likely to be for a few years. There is also more Hyper-V in 2008, but this would likely be covered in a class by itself. I'm assuming this is some sort of intro class. There are still companies out there running Win NT, so while Server 2003 may seem old to you, it is still the new technology to a lot of businesses and 2008 is the new, untested and untrusted tech.

regsvr32 should be working. If you run just regsvr32 by itself, you should get a help menu saying "To register a module, you must provide a binary name..." Does that much work? If not, check your system to see if regsvr32.exe exists. If it does, check to see if it is your system PATH, or try to run it from the directory in which it exists. Is it giving you any sort of error message when you try to run it?

Here is a link explaining how to transfer FSMO roles in Windows Server 2008. You will want to migrate your DNS over, too. If you set up your servers as DNS/AD integrated, then that is already taken care of. Make sure that everything works. Once everything is working, you can run dcpromo.exe on the old server to remove active directory. Before you remove active directory, you may want to shut down the old server and make sure the new one still works. Check the event logs in the new server for errors. You should see some replication errors as it tried to replicate AD info to the server that is now off, but you shouldn't see any major errors. Of course, you'll need to turn it back on before you demote it. This Microsoft technet article is detailed, but confusing. In the interests of completeness, I include it here.

What does the policy do? Have you run rsop.msc or gpresult.exe on the client to see if there are errors trying to apply the policy?

This page has the bare basics for setting up WSUS. That link also has a screenshot of what the policy should look like. If you don't put in the "http://" on the server name it won't work. If the policy isn't applying on your clients, you can use the gpresult.exe and rsop.msc tools to look for errors and troubleshoot group policy. Also, if you did set it to use port 8530, you need to add that to your URL in the gpo, i.e. "http://server:8530"

You don't say what server hardware you are using. There were some HP Proliants where the iLO was causing reboots. If you have one, see HP document c01802766.

If you have no access to the network at all (can't ping anything) and you've already tried turning off firewalls and such, then try uninstalling and reinstalling the NIC.

Under your DHCP scope right-click on the Scope Options and select Configure Options. Find DNS Servers. Add your DNS server IP address. Click Add and then OK. You can also do this same thing under the Server Options, but then if you have multiple scopes they will all get that DNS server.

Right-click the server name in your DNS console. Go to properties and then choose the Forwarders tab. You can enter the ns servers to use for forwarding thing and/or select the checkbox to use root hints if forwarders are not available.

If you don't manually set the TCP/IP info on your clients, then you need to configure your DHCP server to give out the DNS info. Without one or the other, they won't find the DNS server.

If you are creating user accounts, you can use the csvde command line tool. You can also use a VB script to do this, and I believe there are examples floating around the net.

I had a problem like this recently and had to delete the NIC from the device manager on the workstation and then restart the machine and reinstall the NIC. You might also try to do an nslookup for the domain controllers: At the command prompt enter nslookup set type=srv _ldap._tcp.dc._msdcs.domain.name Your domain controller(s) should be listed if configured correctly. (Replace domain.name with your actual domain name)