The Server Roles
IIS (Internet Information Services): The Windows Web Server
IIS is the built-in web server for Windows Server. It is the equivalent of Nginx or Apache on Linux, and it is the standard hosting platform for ASP.NET applications. Many enterprise internal tools, legacy .NET applications, and Microsoft products (SharePoint, Exchange's OWA) run on IIS.
Key IIS concepts:
- Sites: Each website is a separate IIS Site, bound to a hostname, IP address, and port. Multiple sites can run on the same server.
- Application Pools: Each site runs inside an Application Pool — an isolated worker process (
w3wp.exe). If one application crashes, it only takes down its own pool, not other sites. App pools can be configured to run under a specific service account identity, which controls what resources the application can access. web.config: IIS configuration for a specific application lives in aweb.configXML file in the application's root directory. This controls URL rewriting, authentication, custom error pages, and more. It is the equivalent of an Nginxserver {}block.applicationHost.config: The global IIS configuration file, located atC:\Windows\System32\inetsrv\config\applicationHost.config. This is the equivalent of/etc/nginx/nginx.conf.
IIS administration is scriptable through the WebAdministration PowerShell module, which exposes cmdlets to list sites and their status, start or stop a site, enumerate Application Pools, and — critically — recycle a single Application Pool (Restart-WebAppPool) without touching any other pool on the box, the equivalent of restarting one worker process in isolation.
RDP (Remote Desktop Protocol): Graphical Remote Access
RDP is the Windows protocol for graphical remote access — the equivalent of SSH, but instead of a terminal, you get a full graphical desktop. It runs on TCP port 3389 by default.
Unlike SSH, which sends only text commands and their output, RDP streams the entire graphical display, keyboard input, and mouse movements. This makes it bandwidth-intensive but essential for applications that have no CLI interface — legacy GUI-only admin tools, graphical installers, and applications that require a Windows desktop environment.
RDP Security Considerations
RDP has a long history of critical vulnerabilities. The most notable was BlueKeep (CVE-2019-0708), a pre-authentication remote code execution vulnerability that affected millions of unpatched Windows systems. More recently, DejaBlue and other RDP vulnerabilities have been discovered.
Security hardening for RDP:
| Practice | Why |
|---|---|
| Never expose port 3389 to the internet | RDP is a top target for ransomware and brute-force attacks |
| Require VPN before RDP access | Adds an authentication layer before RDP is even reachable |
| Enable Network Level Authentication (NLA) | Requires authentication before a full RDP session is established, reducing attack surface |
| Use RDP Gateways | A dedicated server that proxies RDP connections over HTTPS (port 443), eliminating direct port 3389 exposure |
| Restrict who can RDP via GPO | Limit RDP access to specific AD groups |
For cloud environments (AWS, Azure), the modern approach is to avoid RDP entirely and use AWS Systems Manager Session Manager or Azure Bastion, which provide browser-based or CLI-based access without opening any inbound ports.
If an interviewer asks "How would you securely provide remote access to Windows servers in AWS?", the wrong answer is "open port 3389 in the security group." The right answer is: use AWS Systems Manager Session Manager (no inbound ports required, sessions are logged to CloudWatch/S3, IAM controls access) or an RDP Gateway behind a VPN. Mentioning BlueKeep demonstrates awareness of why this matters.