Principles of delegated administration - Server Tutorial

- [Instructor] IT departments of all sizes benefit from some type of delegated administration. In a large organization, it's easy to see the benefit of assigning out rights and permissions to perform specific administrative tasks. But even my small business clients, the ones that consider me to be their entire IT department want to allow an office manager the ability to create new user accounts, reset passwords, and occasionally set share permissions. The processes for granting these privileges are described in a number of other courses in the library. What I want to focus on is how you can overcome one of the challenges that often accompanies delegating administration. Many IT professionals have grasped the idea that administration doesn't have to be at the server console. Many admins believe that servers should be heard and not seen. But some of the people to whom you delegate administrative tasks may not understand this. If you have an on-prem server, it's tempting for some to think that any administrative task really should be done using a keyboard and monitor that are connected to that machine. This includes some of the last people that you want poking around in there. I'm pretty sure this impulsive office worker is on the phone with tech support asking where to find the any key. Delegating administration, especially to people not experienced in thinking like an administrator requires you to grant the object access needed to complete the task and nothing more. So we keep people away from the server by giving them remote administration tools. These tools have changed several times over the years. They connect to the servers using various types of remote procedure calls, HTTP and HTTPS links, remote desktop sessions, and other types of connections over the intranet or possibly the extranet. Managing access to these various types of connections has become pretty complex With all the different protocols, services, and firewall rules. Microsoft participated in the development of a standardized protocol named WSMan that runs over HTTP or HTTPS. It runs over a specific port, 5985 for HTTP, which can be changed if you want, and this makes PowerShell remoting possible. Remoting, or WinRM, on Windows servers and workstations, is the service that PowerShell uses to run commandlets or entire sessions that access one or multiple remote machines. That's huge. Not only does remoting simplify the firewall rules, but the ability to manage multiple machines in a single command, opens up another benefit of remoting. As an administrator, you can run commandlets or scripts that pull information from, or send tasks to, dozens, hundreds, or even thousands of other machines. You may have noticed the hyphen-ComputerName parameter as an option for several different PowerShell commandlets. Moving forward, we're going to take a look at three different tools that make remoting a valuable administration tool for as many computer names as you wanna list.