All security is managed by roles. In order to be part of a role, a user must have a user account within the CMDB. The user account is associated with an Active Directory account or, in rare cases, an internal credential (used internally by solutions, not people). Roles have privileges (things they can do) and permissions (to whom and how they can do it). To restrict access, you combine reductions in privilege and permissions. Privileges are managed by selecting the role and choosing the Privileges tab. Permissions are managed by choosing the 'Launch Security Role Manager' button from this same tab.
Computers are resources, so permissions can be restricted for these systems. Computers are automatically included in the Default View under Computers or under Computers > Virtual Machines. If you want to differentiate between servers and desktops, you will need to create a new Organizational View. Within the organizational view, create an organizational group for servers and an organizational group for end-user computers. It's likely you'll need to create a group for middleware like site servers as well, and give both roles access to this section for reports and a few other features to work properly (e.g. task status).
For some actions in the console, you must clone the Symantec Administrators role and pare it down. However, for limited roles, you can start with a role like Level 2 Workers and remove some actions and add others. This can prevent you from giving too many privileges to the role. I prefer to clone Symantec Administrators because I know I will not run into bugs from hidden permissions that are missing when you start with a blank role or lower-level role.
With this cloned role pared down and tested for privileges, you now open the Security Role Manager and modify permissions. Work with the Settings view first. A bug exists where loading the Settings picker later will erase other changes you've made. (Obnoxious, I know.) Then go through the other areas, restricting access as necessary. Most of the scoping is going to come from the View: Resources section (when you restrict access to computers and other resources) and the View: Console Menu section (when you remove much of the menu options for the role).
When modifying Resources for these custom roles based off of desktops and servers, you'll want to uncheck all Computer resources in the Default view, as well as any other active views (such as the Active Directory view that is automatically created if you're performing an Active Directory import). The role now has access to no computers at all, so the next step is to give them access to computers in the custom view you created. For the desktop team, this means access to Workstations and Middleware; for the server team, this means access to Servers and Middleware.
As I said, from here you can continue to reduce the Menu items available to them, pare down the ability to access Web Parts, run Reports, view Portal pages, etc. You'll want to test everything important for errors in between each section modification.
If you wanted to just modify security for today's environment, without SMS, you would follow all of the steps except those having to do with the custom views and resources -- just the role-related steps.
Does this help?