How to become a windows sysadminFriday, March 11, 2016 - by Keith A. Smith· Create two networks/VLANs (desktops and servers) · Install Windows Server (VM or standard hardware if you have it available) GUI Mode. · Install another server, single NIC on the server VLAN · Create your first active directory domain controller. · Create another server but this time make it a core server. Make it a domain controller · Test AD replication via the GUI and cmd. · Create an OU for your workstations; create an OU for your users, and an OU for groups. From now on, any new computer or new user account must go into their respective OU. DO NOT MOVE THE DOMAIN CONTROLLERS FROM THE DOMAIN CONTROLLER OU. · Create subnets in Active Directory Sites and Services to match the IP’s used on the VLANs you created. · Check out DNS. Do you have a reverse look up zone? No? Then set it up. · Check out DNS. Records can get old and out of date and will screw up name to IP resolution. Make it so that scavenging happens automatically. · You need to block facebook.com via windows DNS. Make it so that when a DNS look up is performed, computers use a loop back address. Test this via cmd to make sure it resolves as expected. · Set up DHCP on the first domain controller. · Set up a scope to hand out IPs for the Desktop VLAN. Make it so that this DHCP scope will be able to give endpoints the information they need networking wise to join a domain · Install a Windows endpoint or newer PC on the desktop VLAN · Your Windows endpoints are not getting IPs. Why? (hint: it's a routing/broadcast/relay issue) · Join that desktop to the domain · Now that you are getting IPs from your DHCP server, configure DHCP clustering. Load balancing or failover is your choice. Now test it. · Create a non-domain admin account in AD. Fill out the whole profile once the account is created. · Login to that Windows endpoint as a regular AD user and an Admin user. Try to install software under the non-admin account first and then the admin account. What is the difference? · Create another non-admin account. Make this non-admin user a local admin on that computer. Who else is also a local admin before you make any changes, · Review the attributes of that account in AD. You will need advanced features for this. · Create an AD group. Add the first non-admin account to this group. · On that desktop, install the RSAT tools so you can remotely manage another computer · Setup remote management on the core server so that it can be managed from the MMC of another computer (there are a number of ways to do this) · Find out what server is holding the FSMO roles via the GUI and the command prompt. · Split the FSMO roles between the servers. Try to keep forest level and domain level roles together. · On one of the domain controllers, create a file share set it so that only administrators and the second non admin account have access to it. Create another folder and give only the AD group you created permissions. · Use group policy to map both shares as network drives as a computer policy to the endpoint. · Login to the endpoint as the first domain user. Do you see the network drive mapped in windows explorer? No? Use gpresult via the cmd to find out why. If you do see it, try to access the drive. You should be denied if you set permissions correctly. Login as the second domain user, they should be able to open the mapped drive. · What if the account in the group tries to access the second drive? You should be able to get in. · Login to the windows endpoint as the second non-admin account. You should not have access to this drive because you are not in the group. Do not log off. Add this account to the group. Can you access the drive now? No? Logoff and login back in. Can you access the drive now? · Remove the share from the domain controller. We don't like putting shares on domain controllers if we don't have to. · Build out another two servers and join it to the domain as member servers. · Install DFS and File server roles/features on both servers. · Create a file share on bother servers with the same folder name. Create files on both servers. Make sure they are different. (i.e server1 will have "TextDoc01", server 2 will have "TextDoc02" in their shares). · Create a DFS name space. Add those shares to the name space. · On a domain joined endpoint, navigate to the DFS namespace you created. You should be able to see both files. · Create a DFS Replication group. Make it so that you have two way replication. You should now see both files on both servers. Make a change on one server and see if it replicates to another server. Does it work? Great. (you can shut down the file servers for now if you want or use them for the next step) · Configure WSUS so that you will only download Security updates for the desktop and server OS's ( highly recommend that you do not download any updates if you have access to the internet from this server) · Bonus points, install WSUS on another server and create a downstream server) · Create some groups in WSUS. Servers and endpoints will do nicely for names. · Create a new group policy that points workstations into the WSUS workstation group, points to WSUS for updates, and stop workstations from automatically downloading updates. · Read up on approving and pushing updates since the current assumption is that there are no updates to be pushed in this enclosed test network since there is no internet access to down load them. I believe there is a way to manually add updates to WSUS but I'm a bit foggy on that. Research it. · Do the same for servers. · Create a new AD user via powershell. · Create a new AD group via powershell. · Print a list of all domain users and computers in powershell, names only · Use powershell to pull a list of users who have remote as their office. If no users have remote listed as their office, use powershell to set that attribute and then pull users who have remote as their office. · Remove a user account from AD using powershell · Add a user to a group using powershell · Provision new AD users via a CSV in powershell This is really only scratching the surface of a
typical medium-large to enterprise level network. However, this should be
enough to get you started. |
Tweet |