You are here

Research Group Computer Administration


Each research group in CBE, MSE, and/or related research centers needs to declare at least one "Group Administrator" to manage the computers within the group. The role of this person is to serve as a liaison between the group and local IT staff, performing various computer management tasks as approved or mandated by IT staff. Most of the time, such tasks will be limited to software installations, but other tasks may be assigned by IT staff as needs arise.


In order to serve as a Group Administrator, the candidate needs to meet the following requirements:


  • For the sake of communication between all interested parties, the potential Group Administrator must be fluent with the English language.

  • Group Administrators must have at least one year to go on their graduate (or doctoral) studies.

  • Undergraduates may not serve as Group Administrators.

  • Staff researchers are eligible, provided they meet the requirements set forth here.

  • The Group Administrator must use his/her departmental e-mail account (or, equivalently, or Buckeye Mail, but not any other system) to initiate any official e-mail discussion related to his/her role as a Group Administrator. In particular, e-mail requests must be sent from an OSU e-mail server or the Buckeye Mail server. All e-mail communication related to your Group Administrator role must be sent with "<dept>-GRP-ADMIN:" as a prefix to the Subject header content.  In general, the prefix will either be "CBE-GRP-ADMIN" or "MSE-GRP-ADMIN." For example:

    Subject: CBE-Grp-Admin: Software installation request

    (The "Subject:" text is provided for you in your e-mail client; don't actually type this within the text of your message's Subject line. It is included here to show how the full Subject header should look, including the Subject header name.)

  • All such messages are to be sent in plain text, not with anything that would call for you to attach a file to an e-mail message (e.g. an Excel spreadsheet, a Word document, etc.), except if/when providing a quotation for a purchase, which must be provided as an Adobe Acrobat (PDF) file. If you are sending an e-mail message, a request from a Group Administrator should be an e-mail message addressed to Engineering Technology Services (ETS) via etshelp <at> osu <dot> edu. Do not submit Group Admin. requests to individual IT staff members.  You may also submit requests via the Web portal at  When you do so, please use the prefix (described above) in the body of the incident or request you are submitting, as the case may be.

  • A Group Administrator needs to be familiar with and help to enforce all local and OSU policies as they affect computing and networking. Local policies are primarily cited here, which also links to other documents that the Group Administrator should review.

  • Some direct experience with computer administration is preferable.

Designating a Group Administrator

To apply for Group Administrator status, this form must be submitted. Your "letter of justification" (also required) should be based on your requested role as a Group Administrator. All groups must have at least one Group Administrator; larger research groups may be entitled to more. Upon submission of the form, a short interview with IT Management will likely be in order, to ensure the prospective group administrator has the necessary skills.

Faculty who require administrative access need only specify the computer systems on which they need this access; a letter of justification is not necessary, but the submission of this form is still required to document who has administrative access to what computer systems. A&P/CCS staff may request administrative access to the systems they have been specifically assigned.



Group Administrators need to treat their accounts under the same limits imposed on any computer account at OSU. In particular...

Accounts and passwords may not, under any circumstances, be shared with, or used by, persons other than those to whom they have been assigned by the university.(See Policy on Responsible Use of University Computing and Network Resources.)


Under NO circumstances is a (Group) Administrator permitted to use his/her (Group) Administrator account (e.g. "<user>-ga" account) for normal day-to-day activities, or change the security on another account, unless (s)he has the expressed consent of IT Management. Running with elevated privileges for any extended period of time -- especially if you're engaged in activities such as casual Web browsing or reading e-mail -- can and likely will lead to the compromise of the system you are using.


Scope of Responsibility

Group Administrators are responsible for ensuring that all computers in their research groups are configured per policies mandated by the University, the College, and/or departmental IT standards. For the most part, this is handled automatically on systems that are domain members. Standalone systems will require special attention.


Security Advisories


From time to time, IT Management may send out notifications regarding documented security problems with common software. When these notices include instructions on how to deal with the security problem, it is up to you as a Group Administrator to see to it that the corrective action(s) is (are) applied to the computers in your research group as soon as possible.


User Accounts


Windows Domain Members

Access to computers that are members of a domain (e.g. CHBMENG, MATSCENG, etc.) can only be from a domain user account. When a new researcher comes into your group and needs access to a computer that is a domain member, you (as the Group Administrator) need to notify IT Management to create an account for the person in the domain.  When you request an account for a new group member, you should include the new researcher's username and full name, requesting a domain account be created for him/her.  Please also cite the person's "home department" (e.g. degree granting unit).

If the new group member is not a student (such as a post-doctoral researcher, visiting scholar, etc.), you need to check with the department's Human Resource (HR) officer to find out the new group member's "termination date." This is the date the member's appointment is supposed to end, or his/her VISA expiration date (if applicable), whichever is earlier. Send a request for this information to the HR officer, and include his/her response in your request to add the account for the new group member.

Standalone Systems

For standalone computers (i.e. those not part of a Windows domain, including those that run Mac OS X, Linux, Windows, etc.), you need to obtain prior approval for creation of any/all accounts on the system in question. An account for a user on a standalone system should have the same username as that assigned to the account owner's departmental account, where applicable. If the potential user doesn't attend or work at OSU, the username should be based on the person's last name, adding the first initial in cases of name conflicts. Any user who is not officially affiliated with OSU (enrolled or employed) is allowed ONE account (and ONLY one account) on a given system. The account must specify the account owner's full name in the appropriate field. Non-affiliated personnel are ONLY entitled to accounts on OSU systems if they have a business relationship with an OSU affiliate. For example, a hardware technician would be a logical choice for someone who might need a computer account on an OSU computer; an acquaintance with no formal tie to OSU would not be an appropriate candidate for an account on an OSU computer system.


Account Removal


If someone leaves your research group, it is not appropriate to arbitrarily remove the user's account(s). Instead, if you are concerned with the (former) user's access to a group computer, the account(s) should merely be disabled. For domain accounts, please send a message to IT Management with the person's domain username, and be sure to CC your group faculty advisor. (The CC ensures that the faculty advisor is aware of the situation.) Upon receipt of this message, the account will be disabled. For "standalone" computers, the same kind of e-mail message should be sent to notify IT Management (and your advisor), but you don't need to wait for a response to disable the account (but it's probably a good idea to send the message first, and then disable the account).


Remote Access on Windows PCs


It is common to work on Windows computers using Remote Desktop. As a Group Administrator, you are authorized to assign this capability to any account on the PCs in your group, assuming that account has been approved for creation (if on a standalone PC), or IT Management has created it (on a domain PC).

(This assumes use of Windows 7.) To add a user to the list of accounts permitted to access a PC via Remote Desktop, start by logging into your Group Administrator account (if applicable). From the Start menu, access the System control panel. Now click on "Remote settings." In the dialog under "Remote Desktop," make sure the option to "Allow connections from computers running any version of Remote Desktop (less secure)" is enabled. Next, click on "Select Users..." In the list which appears, click on the Add... button and enter the username of the account, qualified with the appropriate domain name (on a domain PC). (On a standalone [workgroup member] PC, you just need to enter the username.) For example, on a PC in the CHBMENG domain, if you want to add Remote Desktop access for someone with the username of SMITH, you'd enter...




...into the "object name" list. Similarly, for someone with the username of BROWN to access Remote Desktop on a PC in the MATSCENG domain, you'd enter...


When the user attempts to login via Remote Desktop for the first time, (s)he will likely need to specify the username with the domain name prefix as above. After logging out of the remote system, subsequent attempts to login from the same local computer should remember the username.


Note that logging out is not the same as disconnecting from a Remote Desktop session.  You disconnect when you press the "X" in the title bar of a Remote Desktop session.  Until you actually logout at least once, your username will not be remembered on your local system.  Whether you initiate a disconnected session or your connection is broken, which would amount to the same thing, the session will remain on the remote computer.  Generally, only re-connecting and then logging out (or restarting the remote system) will end a Remote Desktop session.  Typically, when you're done accessing a system via Remote Desktop, you should logout, not disconnect.  You should only disconnect when you need to come back to the session as you left it.

Related Information

Departmental networking policies

Computer equipment and software acquisition process

Software installation approval