The initial promise of the NMCI Science and Technology (or S&T) seat was great. Some call it a "developer's" account or "dot dev" after the login name but it is all the same thing. Users believed that they would have significant advantages over the standard NMCI user seat. Indeed, the S&T seat was conceived to answer the needs of the programmers, developers, engineers and technicians that required more control over their computing environment. What these power users received was something less than they expected.
Let's take a look at some of the common beliefs about the S&T seat and see what is true and what isn't true. We make no judgment on some of these policies as a few of them "come with the territory" when you subscribe to a managed IT paradigm and would probably be imposed on any managed IT user in any corporate setting. As always, we leave the cost vs. benefit evaluation of this managed IT world to the reader.
S&T users have administrative privileges on their computers
This is only partially true. One also has to place this within the context of other restrictions placed on the NMCI user, many of which will be discussed below. S&T users do indeed have administrative privileges however some of the common things that an administrator would want or need to do are not possible as an S&T user.
Simply logging in to the Microsoft Windows Update site to install security updates is not allowed. This is understandable when you consider that NMCI and the Navy have carefully carved their NMCI seats into a very custom build with some security/performance updates installed and others not installed. Although this is not a completely uncommon practice among managed IT systems, there is always something to be said for simply keeping everything current. Much of the tripe circulating in IT circles about "black Tuesday" upgrades breaking machines is nothing short of rumor and anti-Microsoft propaganda. Millions of fully updated users can prove this pick-and-choose methodology wrong every day. Trying to juggle various updates (for an outdated operating system such as Windows 2000) and installing some and not installing others proves to be very difficult and often needlessly exposes users to security vulnerabilities.
If an S&T user attempts to use Windows Task Manager to cancel a zombie (or annoying) process, there is no guarantee such an action will meet with success. Often such attempts will be met with "Operation could not be completed. Access is denied."
There are likely other Administrator actions, like Windows Update, that are physically blocked or broken to the S&T user. Yet by far, most of the capabilities of an Administrator user are blocked by policy and rule rather than hard, OS-based enforcement. Many of these are discussed in the following paragraphs.
S&T users can install any software they want
This is categorically false. Although the operating system, as configured, may not prevent an S&T user from installing software even if registry changes are required, it is against NMCI policy to do so. Even installing something as innocuous as an updated Microsoft hardware driver is not allowed.
Of course NMCI requires the computer user to have valid licenses for all installed software. This is nothing unusual. What is unusual is that even if the user has a boxed, licensed copy of a piece of software, there is no guarantee that they can install it. The software must be on a list of approved applications. The exact version the user wishes to install must also be on the list. If it isn't, the user's only recourse is to submit the desired software to NMCI for approval. The vaunted approval process has been tried by only a few hearty souls willing to endure the costly and lengthy process of having NMCI technicians test and endorse the software. One could say, "Well, of course they don't want users installing random software, it could break the OS/computer/network!" This would be true except for one thing: NMCI throws its S&T users to the wolves anyway. See S&T users can not call the help desk below.
So suppose an S&T user is lucky enough to find his desired application on the approved list. He still has to notify his local NMCI officials that he is installing the software and submit paperwork to do so. Any software found installed on a system that is not part of an official push or a documented subsequent S&T install is grounds for immediate revocation of user privileges and disciplinary action.
S&T seats are not allowed access to E-mail
This is true while logged in as the S&T user. Although we have reports of several S&T users who regularly access NMCI email (normally sent to their non-S&T accounts) this is still, as far as we know, prohibited under NMCI policy. This requires S&T users to log out of their S&T accounts and log back in as a non-S&T user just to check their E-mail, several times a day. One could speculate on the reason for this policy however we would hope that it is being done for security reasons.
S&T users can not do custom network applications
This is true at most sites on most network segments. The S&T user is subjected to the same draconian IP network filtering as the non-S&T user. There are no open ports except those that are proxied by NMCI proxy servers. This makes custom network applications impossible to test on the NMCI network. S&T seats could easily be placed on a VLAN to keep them separate from the protected non-S&T network and allow S&T users the flexibility they need to work with network-intensive applications.
S&T users have access to BuRAS
This is false. It is more false than it might first appear. S&T users are not only prohibited from using BuRAS while they are logged in as S&T users, they can't even use it while they are logged in as regular users. In fact, NMCI has refused to push the BuRAS software to any machine that is operated as an S&T seat. So even if the user has never logged in to his S&T account, he does not have the same BuRAS capability as the non-S&T user sitting next to him. This policy is supposed to change in the near future but as it presently stands, the S&T user is on the losing end again.
Software development is impossible on an S&T seat
This is true. This is another example where NMCI policy oversteps the physical limitations on the administrative user. Even if the user installs a compiler that is from the approved application list he is violating policy simply by compiling source code. Part of the agreement for S&T users is that they will not "execute, install or compile" non approved code. Obviously if they are developing new software, it is not on the approved application list.
S&T users can not call the help desk
This is partially -- the most important part -- true. Science and Technology users are welcome to call the help desk as long as it doesn't involve a software issue. It doesn't matter if the user has never installed anything on the computer. NMCI has deemed S&T users as experts and throws them to the wolves in terms of help desk support. The actual CLIN says, "Customer support will be limited to those services offered by EDS and not extend to software or hardware loaded and configured by the user." Yet in reality S&T users are told not to call the help desk for anything remotely related to software. So one could ask, "If they are not going to support me, why can't I install any software I want?" If the help desk is going to treat S&T users differently whether they install some bizarre piece of software or nothing at all, why put restrictions on the software?
There are probably other fine points of the Science and Technology lifestyle that we haven't discussed here but we hope the above items are enough food for thought. One now has to ask, "Is all this really worth an extra $25 per month?"
