1. Install the Remote Server Administration Tools (RSAT).
2. Go to Control Panel -> Programs and Features -> Turn Windows features on or off
3. In the treeview, go to Remote Server Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools and select AD DS Tools. Click OK.

NETDOM should be located in your SYSTEM32 folder. If would rather use Powershell to join the domain, since it’s included with the Windows 7 RTM, then please continue reading. I apologize for any confusion.

(Begin Original Post)

Now that the title of this post has your attention, I can tell you that Windows 7 isn’t really missing this important tool that joins a machine to an Active Directory Domain in an automated fashion. Instead, this command-line utility has been superseded by a new command that’s included in Microsoft’s love-it-or-hate-it command line shell: Windows Powershell. Why? Well, Powershell is certainly more powerful than the standard command prompt. But more importantly, Windows 7 is the first version to include Windows Powershell in the RTM build. With Powershell built into Windows 7, perhaps Microsoft saw no reason to continue including and supporting our old pal, NETDOM.

Joining a Domain with Add-Computer

When you’re finished grieving over the loss of our beloved NETDOM, which has joined countless computers to countless Windows Domains (or far inferior Workgroups), it’s time to roll up your sleeves and start working with the successor command: Add-Computer. This command will only run in a Windows Powershell command prompt. The good news, however, is that you can easily run Add-Computer inside Powershell through a normal command prompt (or batch file). To do so, open a command prompt (with elevated privileges) and run this command:

powershell Add-Computer -DomainName "YOURDOMAIN"

See? That wasn’t so bad now was it? If you don’t mind entering credentials to join the domain on every single computer, that’s all you need. But unfortunately, some of us need to automate the process of joining the domain. For that, it gets more complex, and we’ll need a bit more Powershell to make it work.

Screenshot: Add-Computer -?

How to Use Add-Computer

From a command prompt, you can get more detailed usage instructions for Add-Computer by using this command:

powershell Add-Computer -?

In the syntax section, you’ll find syntax switches that can be used to specify the domain name, OU path, and credentials.  For a more details and examples on Add-Computer, you can also use this command:

powershell get-help Add-Computer -detailed

The first thing you should notice is that, unlike NETDOM, there aren’t syntax switches to specify the username and password. Instead, there is a switch called “-Credential” that takes in a PSCredential object. Therefore, we need to create a PSCredential object with the credentials that will be used to join the computer to the domain before we can actually use the Add-Computer command in an automated way. To do this, we’ll need to create a Powershell script.

If you have never used Powershell before, you’ll probably say to yourself, “PSCredential object? What is that!?”  I’ll give you this very brief explanation: PSCredential is an object that can securely store Windows credentials. Furthermore, Powershell is  more like full-blown Object-Oriented scripting language than a shell language. Like DOS, it has a command prompt. However, the differences usually end there.  Anyway, this article isn’t about Powershell, but if you want to know more about it, start Googling. Or you can just continue on to get the Powershell script.

A Powershell Script to Join the Domain

The Powershell script needed to join the domain contains only two commands.  Create a new text file named “joinDomain.ps1″ and put the following powershell code into it:

$credential = New-Object System.Management.Automation.PsCredential("MY.DOMAIN.COM\user", (ConvertTo-SecureString "mypassword" -AsPlainText -Force))
Add-Computer -DomainName "MY.DOMAIN.COM" -Credential $credential -OUPath ("OU=Computers,DC=MY,DC=DOMAIN,DC=COM")

The first line of the script creates a new System.Management.Automation.PsCredential object. PsCredential takes in two parameters: a string containing a username and a secure string containing the password.  You should change “MY.DOMAIN.COM\user” to the user that will join the computer to the domain. Change “mypassword” to the password of that account.

The second line is the Add-Computer command. “MY.DOMAIN.COM” should be changed to the domain that the computer is joining.  Change OUPath to the OU String that points to the OU container that the computer object should be placed in.

Running the Script

To run the Powershell script above, you need to open an elevated command prompt. To run it, type powershell ./joinDomain.ps1 and press enter. In many cases, you will find that you’re not allowed to run the script, despite running the command as an administrator:

>powershell ./joinDomain.ps1
File joinDomain.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.

The funny part about Powershell is that, by default, it is configured to only allow the execution of signed scripts. This is a security feature so that unauthorized or malicious scripts that could compromise the system can’t be executed. After all, Powershell is quite power-ful. Unfortunately, this really tends to confuse and frustrate people. To get around this, you can temporarily change the execution policy, and then change it back:

powershell Set-ExecutionPolicy Unrestricted
powershell ./joinDomain.ps1
powershell Set-ExecutionPolicy Restricted

You can also change the execution policy to allow only signed scripts and scripts created by you. For more information about the Powershell execution policy, check out this article.

Final Thoughts

Now that you are able to automate a domain join with Powershell instead of NETDOM, there is one final thing that I want to mention. In the script above,  the password String was converted to a SecureString by using the “-AsPlainText -Force” arguments. Using SecureString in this way is generally discouraged as it defeats the whole purpose of having a secure string. Furthermore,  having account credentials in plain text with in the script is insecure and generally a bad idea. I’m guessing that this is the reason why Microsoft left out the “/userD” and “/passwordD” parameters from the NETDOM command and made it more slightly difficult to include the credentials in plain text. You should limit the rights of the account you’re using to automatically join the domain so that it cannot be used to delete Active Directory objects, access network shares, etc. You should also consider other methods of storing the credentials. This article has an alternative method for storing credentials used in Powershell that may meet your needs.

While upgrading the WinPE image from 2.0 to 3.0 in anticipation of deploying Windows 7, I discovered that the Windows PE 3.0 base image (the same one that comes with the Windows AIK) was missing Win32_DiskPartition. I use this class to retrieve the number of partitions on the system disk so that I can make sure that each partitition (and its volume) has been assigned a drive letter so that I can search each drive for a preexisting configuration file. But why would Microsoft remove this class!? On a standard Windows 7 machine, the command “WMIC.EXE PARTITION” returned a list of partitions on the system, confirming that I wasn’t losing my mind. However, the command returned nothing when I tried it in Windows PE 3.0.

After lots of searching, I finally came across a post on Microsoft Technet where another developer ran into the same issue. Fortunately, he found a simple, but somewhat obscure, solution:

1. On a fully-installed Windows 7 machine, copy the contents of C:\Windows\System32\wbem
2. Mount the Windows PE 3.0 image and replace the contents of <mountdir>\Windows\System32\wbem with the wbem folder from the previous step

Using the Windows 7 wbem folder in your WinPE 3.0 image will make it several Megabytes larger, but at least you will be able to get to the missing WMI class(es) that you need!

Update 3/11/2010: After upgrading to the latest version of the Microsoft WAIK, I was unable to overwrite existing files in the WBEM folder (Access Denied). For some reason, the permissions are different on this folder now. Here is the workaround:

1. To take ownership of the existing WBEM folder and files, run this command: TAKEOWN /F <mountdir>\windows\system32\wbem /A /R
2. To grant administrators full control of the existing WBEM folder and files, run this command: ICACLS <mountdir>\windows\system32\wbem /grant Administrators:F /T

Once the permissions are updated, you will be able to overwrite files in the WBEM folder.

Why are we looking to use SCCM when there is an additional per-machine cost? Well, we see several advantages that we need in order to be able to continue to expand out Computer Management project:

• No MSIs required – SCCM will hopefully allow us to deploy software without needing an expensive packaging application such as WISE. Not to mention, there are a lot of applications that work very poorly when packaged with MSIs, such as Office 2007 and Adobe Creative Suite). Furthermore, there are some MSI packages that conflict with others and can inevitably make a machine build fail.
• Better software deployment management – Hopefully, SCCM will allow us to be more granular when it comes to choosing which computers get what software.
• Machine Inventory/Queries – Currently, we use applications developed in-house to perform WMI queries against machines for Inventory purposes. Inventory is stored in a SQL database and queries can be performed using a web page. Quite frankly, this is code we would rather not maintain in the future. The SCCM Configmgr interface should allow us to inventory machines while also to grant access to are partners to that they can query their machines. In other words, we no longer have to reinvent the wheel. Inventory should also be more reliable.
• Offsite deployment – Currently, any machines in CLM must be connected to the Penn State network in order to be managed and receive software. This makes managing offsite devices, such as laptops, impossible. SCCM has functionality that could allow us to manage and deploy software to offsite systems through HTTPS.
• Streamlined Operating System Deployments – Thanks to the Operating System Deployment (OSD) portion of SCCM, we will hopefully be able to rapidly create, configure, and deploy Windows to machines using a variety of distribution mechanisms including PXE, USB Drives, and DVD Media. We hope to incorporate all of the features of our current imaging process into this. SCCM OSD also uses ImageX to create images similar in the way that Symantec Ghost does. This should eliminate our dependency on Ghost licensing.

We’re still investigating SCCM and there are several experiments under way. One thing that I have found is SCCM does not support OS deployments via a restore partition on the physical disk. This is a requirement for us because we have a lab environmment where an entire lab of 50+ machines may need rebuilt over. Pushing out the OS over the network could eat up a lot more bandwidth than is necessary. We will have to find a way to work around this, which probably means throwing out the native SCCM boot shell (TSBootShell.exe) and writing a simple one that meets our needs.

On Friday, an announcement was made that beginning this week, bandwidth limits will increase from 2GB/week to 4GB/week. Additionally, network throughput during the day would increase 120%. This is a major improvement for the residence halls. However, it should not make us forget about improving the service in the long-term. Here are my suggestions for ResCom, which I presented to University administrators 2 weeks ago in a formal letter:

Increasing Bandwidth Limits

In the immediate future, I believe that the weekly commodity bandwidth limit for students should be increased to 6GB/download and 4GB/upload per week. The download limit should be set higher than upload limits because, in my opinion, it is more important than upload bandwidth. In my experience, users that have exceeded the 2GB upload limit typically have file sharing applications running in the background that are abusing bandwidth and often sharing copyright material. These limits also meet the minimum of what I believe are the next-lowest bandwidth limits in the Big Ten. Wisconsin-Madison permits users 10GB total of off-campus bandwidth over any seven-day period.

Since a large number of students in the residence halls have received bandwidth violations at the current limits, I recommend that one or two violations be removed from their semester count if new limits are set in the middle of this semester. This would give them a fair opportunity to obey the new and more reasonable limits.

Allocating More Bandwidth to the Residence Halls

In order to increase the amount of bandwidth allocated to the residence halls, I recommend that Auxiliary and Business Services purchase additional internet commodity bandwidth for use in the residence halls. In my opinion, the residence halls should not be entitled to use commodity internet bandwidth that is paid for with the Information Technology Fee. This fee should support all students, and since the ResCom service is only available to students living in University residence halls, I believe it is unfair to students with off-campus housing that pay this fee.

Additionally, I have discovered that many students are confused by the differences between bandwidth limits and bandwidth caps on commodity internet connectivity. In the future, it may be clearer to define bandwidth caps as throughput caps since speed is what seems to be what this cap is limiting, not the amount that can be downloaded or uploaded in a week.

Annually Reviewing Bandwidth Limits and Policies

According to an archived copy of the ResCom bandwidth FAQ, Housing and Residence Life should have implemented a formal policy that would govern residence hall network bandwidth usage. ARHS and CCSG were to be consulted in the development of this policy. However, I am not aware of this policy ever being created or implemented. I would like to see this policy created or re-evaluated in order to create an annual review process for residence hall bandwidth limits. Things that should be included in the process are statistical data on bandwidth use as well as feedback from students. I believe that implementing an annual review committee that consists of staff from both Auxiliary & Business Services and Telecommunications & Networking Services, as well as student representation from organizations such as ARHS and CCSG, would be helpful to consistently analyze internet connectivity needs in the residence halls.

An online survey may also be useful for getting feedback from students regarding the ResCom service. This may help determine general satisfaction with ResCom customer service, bandwidth limits, and connection speeds. While I cannot guarantee that there would be a high volume of responses, I still think it is important to give students the opportunity to supply feedback.

Dealing with Repeat Bandwidth Violations

Although there may be little excuse for someone to receive three bandwidth violations under higher limits, I realize that these users still have legitimate work to do. While there should be a throttle for repeat offenders, I think it should be raised to something reasonable, such as 256Kb/s or 384Kb/s. Also, I do not believe that this throttle should affect access to sites on the Penn State network. This would make most web services that are vital to a student’s education at the University usable.

Improving the User Experience

While the issue of the moment seems to be bandwidth, I believe that several other processes within ResCom need to be improved in order to offer a service comparable to that of other Universities. As the former ResCom Student Supervisor at Penn State Mont Alto, I have seen the confusion caused by computers that have multiple Ethernet Addresses and IP Configurations. Implementing DHCP was a step in the right direction. However, the process would be much more efficient if more responsibility was taken out of the user’s hands. Additionally, allowing students to register with ResCom over their inactive connection would save them the hassle of finding another computer with internet access. I have seen examples from other Universities that automatically redirect students to a “remediation zone” prior to registering that only allows them to access the registration website. Automatically redirecting the user to this site after they plug in their network cable could further improve the experience.

Network Access Controls (NAC) will also need to be updated to improve both the registration and network security aspects of ResCom. Newer Network Access Protection (NAP) solutions could proactively help provision student computers by making sure they have the latest operating system updates and antivirus definitions. This would improve network security and, in my opinion, potentially cut costs by working to reduce the number of compromised machines on the network that ResCom and Security Operations Services must support.

WSUS has a lot of great features that System Administrators can take advantage of. More information on it is available at this address: http://technet.microsoft.com/en-us/wsus/default.aspx

One of the interesting outcomes of the SACITS meetings was that ITS has already looked at providing this service to users. In fact, the service is already being offered: http://aset.its.psu.edu/docs/windows/windows_sus . So why isn’t it advertised to students? The answer at the meeting seemed to be that there wasn’t a easy, foolproof way for students to configure their machine to use the Penn State WSUS server. Additionally, there wasn’t an easy way to set the update configuration such that when students took their machines off the Penn State network, the configuration would automatically revert back to Microsoft’s servers. I disagree.

In fact, I’m pretty sure that all of this can be configured easily using a few registry tweaks and a batch file, maybe two.

IMPORTANT: I haven’t confirmed that all of this works flawlessly yet, mainly because I don’t live in a residence hall. If you try it and run in to problems, please post them in the comments. This will only work in Windows XP/Vista

DISCLAIMER: How to Break Your Computer
It’s no secret that improperly making changes to the system registry can really mess things up on your computer. While making registry changes is normally straightforward, it isn’t foolproof. However, a small application or batch file can be written that helps automate the registry changes that need to be done to configure WSUS. An example is below. If you decide to make any changes manually, please do so at your own risk.

Also, if you decide to use any text or files from this article, please do so at your own risk. I take no responsibility for any problems you encounter with this information. By using the batch files on this page, you agree that I hold no responsibility for unintentional damage caused. You also agree that I am not obligated to provide technical support regarding this article or any files included in it. Sorry, had to get that out there.

We Don’t Need No GPO
For system administrators that manage computers through an Active Directory environment, configuring clients to use a WSUS server involves creating a fairly simple Group Policy Object (GPO). However, users in the residence halls aren’t joined to a domain, for better or worse. Fortunately, machines can still be manually configured to use a WSUS server by modifying the registry: http://technet2.microsoft.com/windowsserver/en/library/75ee9da8-0ffd-400c-b722-aeafdb68ceb31033.mspx?mfr=true. Once the needed registry settings are applied, the Automatic updates service needs to be restarted.

The Building Blocks
For this task, writing a small batch file is quicker (but also dirtier) than writing an actual program.  We can use commands that are readily available in DOS to make changes to the registry. The REG ADD command makes adding/updating registry entries easily scriptable.

NET STOP wuauserv

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v ElevateNonAdmins /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v TargetGroupEnabled /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 1 /f

NET START wuauserv

The last REG ADD command adds (or updates) the UseWUServer value. When this value is set to 1, the Automatic Updates service should use WSUS servers (if they have been specified). When set to 0, Microsoft Windows Update servers should be used. Finally, for the configuration to take effect, the Automatic Updates service (wuauserv) needs to be restarted using the NET STOP and NET START commands as shown above. The above code would be great if we wanted to always use the Penn State WSUS server. However, we want to use microsoft’s servers when we aren’t on campus. Also, Penn State may decide to block internet traffic from using the WSUS server in the future. This could potentially lead to a lot of missed updates. Alright, this will makes it a bit more complicated.

A Bit More Thorough
The above commands are probably the easiest way to do a one-time configuration of WSUS. However, if we want a “set it and forget it” approach that uses Windows Update when off-campus, things need to be a bit more advanced. The plan: write a batch file will “install” a scheduled task that checks to see if we’re in or out of the Penn State network. This one batch file should take care of installation and configuration:
Note: to use the code below, copy it and then paste it into blank notepad file. Save the file with a .BAT extension (ex: PSUWSUS.BAT). Then, browse to the file and double click it.

@ECHO OFF

ECHO WSUS Config Check Installer
ECHO Creating batch file in C:\WSUSCHECK.BAT
ECHO ping udrive.win.psu.edu > C:\WSUSCHECK.BAT
ECHO IF %%ERRORLEVEL%% NEQ 0 GOTO OFFCAMPUS >> C:\WSUSCHECK.BAT
ECHO IF %%ERRORLEVEL%% EQU 0 GOTO ONCAMPUS >> C:\WSUSCHECK.BAT
ECHO. >> C:\WSUSCHECK.BAT
ECHO :OFFCAMPUS >> C:\WSUSCHECK.BAT
ECHO NET STOP wuauserv >> C:\WSUSCHECK.BAT
ECHO REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 0 /f >> C:\WSUSCHECK.BAT
ECHO NET START wuauserv >> C:\WSUSCHECK.BAT
ECHO GOTO END >> C:\WSUSCHECK.BAT
ECHO. >> C:\WSUSCHECK.BAT
ECHO :ONCAMPUS >> C:\WSUSCHECK.BAT
ECHO NET STOP wuauserv >> C:\WSUSCHECK.BAT
ECHO REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 1 /f >> C:\WSUSCHECK.BAT
ECHO NET START wuauserv >> C:\WSUSCHECK.BAT
ECHO GOTO END >> C:\WSUSCHECK.BAT

ECHO :END >> C:\WSUSCHECK.BAT

ECHO Creating a Scheduled Task…
schtasks /create /tn WSUSCheck /tr c:\WSUSCHECK.BAT /sc hourly /mo 8 /ru SYSTEM

ECHO Applying WSUS Settings…

NET STOP wuauserv

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v ElevateNonAdmins /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v TargetGroupEnabled /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 1 /f

NET START wuauserv

ECHO Installation Complete. Please look through the script for errors and report them if necessary.
pause

To summarize, this script outputs text to C:\WSUSCHECK.BAT. This text, when executed, is what actually checks to see if the machine is on campus or off campus. The check is done by pinging udrive.win.psu.edu. This is a server uses a private, non-routable IP address that should only respond to ping when the machine is connected to the Penn State network. The script adds the Penn State WSUS server to the registry and creates scheduled task that runs C:\WSUSCHECK.BAT every 8 hours.

A Few Notes
There is one caveat to this batch file: If for some reason the ‘udrive.win.psu.edu’ stops responding to ping requests, the batch file will always think that it is off the Penn State network. This is not the perfect solution but instead a working example of how one might approach the problem. If you have a better method, please post it in the comments. Ping was just the first thing to come to mind.

Another thing I don’t like about this batch file is that it restarts the Automatic Update service every 8 hours regardless of whether or not settings are modified. I debated trying to make the batch file smarter by checking if the UseWUServer is actually being set to a different value and then restarting the service if it is. However, I couldn’t find any reason why restarting the Automatic Update service periodically would be a bad thing. Feel free to convince me otherwise in case I missed something.

What is WebAccess?

(via https://webaccess.psu.edu/help.html)
“The WebAccess system, which uses the University of Michigan’s Cosign technology (a development effort that is funded by the National Science Foundation’s National Middleware Initiative-Enterprise and Desktop Technologies program), provides an environment in which users authenticate/login once with their respective Access Account userids and password to a central server in order to access multiple services protected with WebAccess without needing to re-authenticate. For example, a user can authenticate via Penn State WebAccess and then access services such as the Penn State Portal, Penn State WebMail, and a variety of other WebAccess-enabled, without needing to authenticate again to those services.”

In a Nutshell:

WebAccess allows those with Penn State Access Accounts (or Friends of Penn State accounts) to use the same username and password for multiple websites. This document will help explain how you can incorporate WebAccess into your websites to help protect content that you want or need to limit access to.

Reasons for using WebAccess

If you need a way to protect content on your club website you should consider using Penn State WebAccess for some of the following reasons:
• Secure – WebAccess is a secure way for your users to authenticate and access content on your club site. Additionally, passwords are sent over the internet in encrypted form using Secure Sockets Layer (SSL).
• Liability – Storing user credentials could potentially make you liable if your club website were compromised. With WebAccess, user credentials are never stored in your club web space and no one (including yourself) has access to those credentials.
• Easy – Using WebAccess for authentication is usually much easier than trying to implement a secure login program for you club website on your own.
• Improved User Experience – WebAccess is part of Penn State’s Single Sign-on Solution (SSO) which means users don’t need to register or log in with a different username and password before they gain access to protected content. As long as the user has a Penn State (or Friends of Penn State) access account they will be able to log in.

Reasons for NOT using WebAccess

Of course, WebAccess shouldn’t be used for everything. Here are some examples:
• Public Information – If there is information on your club website that you want the general public to see, you may not want to use WebAccess since guests as well as search engines will not be able to access it. However, if there is certain information on your site that you would like to restrict access to, you may want to try keeping it in a separate folder that you can apply WebAccess authentication to. Deciding what should be public and private content is an important consideration when designing your club site.
• Integration – Integrating WebAccess into an existing web script (such as a discussion forum) can sometimes be difficult and may require programming knowledge. If you’re looking to replace an application’s preexisting registration/login mechanism, prepare to dive into some code. However, if you just need to restrict access to a specific folder on your website, WebAccess is still the way to go and relatively easy.

Requirements

Currently, the only way to enable WebAccess is through php.scripts.psu.edu. Therefore, you must forward all traffic to this server. If you’re already writing your site in PHP, you can skip this step since files ending in ‘.php’ are automatically redirected to the php.scripts server.

Installation Steps

1. Put all of the content you want to protect in a subfolder on your website.
2. Send an e-mail to dbadmin@aset.psu.edu with the url to the folder that you want webaccess enabled on.
3. You’ll receive a reply with the new URL to that folder. You’ll probably also be given the option to either continue to allow access to the folder from the old URL (unauthenticated) or disable that access. In most cases, you want to disable this access otherwise it sort of defeats the purpose.

Limiting Access to Certain Penn State Users

In many cases, you may want to grant access to private content to only a few Penn State users. This can be done quickly and easily using .htaccess. In the folder that’s protected by WebAccess, create a new file named .htaccess. Open .htaccess and paste the following:

AuthType Cosign
require user abc000 def548 ghi984

Replace the fake usernames in the second line with the names of the users that you want to grant access. You may add as many users as needed to that line.