Thursday, April 2, 2009

Specialized Local Administrators

Many times we come across scenarios that are fairly difficult to quantify or to create a technical solution that satisfies all of the requirements. I came across one such scenario that I would like to share to see if anyone may benefit from my solution.

The scenario is this, how can I add a domain user or group to the local administrators group of all of my desktops to facilitate a 'desktop support' group admin access to all desktops without giving them domain admin rights. I know a lot of you are thinking, just use group policy and create a restricted group. Well that would work for a very generic and probably small organization. We have a decent sized organization, 1500+ workstations, 90+ Windows servers, and 70+ locations. Well, like many organizations, we have vendors that offer low cost software solutions, but these solutions many times have not been updated to ensure the security of the workstations or servers. The main thing I am talking about is requiring local Admin privileges to run a poorly written application. So I have many desktops out on the network that may or may not have a specific user listed in the local Admin group. As most of you know, using the group policy method with a restricted group, this method actually replaces all users in the local group with the users you specify in the policy, so this was not a good method for our environment. After much thought and experimentation, I came up with a script that can be applied as a computer based startup script in group policy to add a specific domain user or group to the local administrator group of the machines that the policy applies to.

Below is the script, this script also ensures that no one has removed Domain Admins from the local administrators group (which has happened before in my environment). As you can see from the commented lines below, the group I used is called 'WSAdmins', just change this to whatever you want to use and be sure to change the tag to your NetBIOS domain name. Also, I am no professional coder, the code below is the only way I could get this script to work, if you have another way to clean this up, please drop me a line.

______________________________________

' Script to add the WSAdmins and Domain Admins domain group to the local administrators group


' These two lines enumerates the computername from the local environment
Set Shell = WScript.CreateObject("WScript.Shell")
strComputer = "."

Set objAdmins = GetObject("WinNT://" & strComputer & "/Administrators")

i = 0

For Each objUser in objAdmins.Members
  If objUser.name = "WSAdmins" then
    Wadd=1
  End If
  If objUser.name = "Domain Admins" then
    Dadd=2
  End If
Next

If Wadd = 0 then
  ' The next line binds to the local Administrators group and to the grop you wish added
  Set objGroup = GetObject("WinNT://
<domain>/WSAdmins")
  ' The last line adds the user to the local Administrators group
  objAdmins.Add(objGroup.ADsPath)
Else
  ' The next line is commented out for testing
  'wscript.echo(strComputer & " already has WSadmins")

End If

If Dadd = 0 then
' The next line binds to the local Administrators group and to the group you wish added
  Set objGroup = GetObject("WinNT://
<domain>/Domain Admins")
  ' The last line adds the user to the local Administrators group
  objAdmins.Add(objGroup.ADsPath)
Else
  ' The next line is commented out for testing
  'wscript.echo(strComputer & " already has Domain Admins")

End If



After you modify the script to work in your environment, just added to a Group Policy Object as a Computer Startup Script. Like I said, this works well in my environment, if you have another way, post a comment and share it with everyone.

Till next time...

RB Out.



Friday, March 6, 2009

Exchange 2003 to 2007 Migration

I recently migrated our organization to Exchange 2007 from 2003. I must say, the documentation from Microsoft was fairly well laid out and it seemed to be a straightforward migration, but alas, with many things from Microsoft, it was not to be.

Everything went really well for us until it was time to remove the last Exchange 2003 server from the organization.

The first sticking point was, for some reason or another, ten out of my forty or so public folders failed to replicate correctly/completely, even after I had issued the 'Move All Public Folders' command from ESM and ran the EMS script to move the public folders. To this day I do not know if it was some corrupted items within the folder or some other anomoly, but this is how I managed to get them moved.


My first step after monitoring the event viewers for several days full of frustration and hair pulling, I broke down and called Microsoft. This was a great use of time and money (oh, look at the puddles of sarcasm all around). Truthfully, more times than not, when I call Microsoft, what I receive as help is exactly what I have already tried. Really, do these support techs and more to the point, the support management, think we,as IT professionals, do not know how to search the internet for solutions to our problems before we call a support number. I personally despise calling support numbers because the techs you are normally able to talk to are just screen readers and do not have any real troubleshooting skills.

Anyway, that was my rant for today.

Once I realized the support person was not going to help that much, I started thinking of ways around my problem. I then realized, my users we all on 2007, and all of my mailbox stores were pointed to the 2007 Public Folders. The only reason for the existence of 2003 was the public folder referrals I was encountering because of the hung public folder instances. For the solution to this problem, I clicked and dragged the folder in question to basically make a copy of that folder, just like in Windows, I ended up with the same folder name with a number after it, i.e. Stuff & Stuff1. Since my mailstores were pointed to the new Public Folders store, the copy I just made instantly went into the 2007 Public Folders store. All I had to do next was delete the old public folder and rename the new one (remove the number from the end), and voila... problem solved.

The last piece of the problem came when I tried to uninstall the last Exchange 2003 server from the domain. The uninstaller was complaining that I couldn't do this until all users were moved to another mail store. I double checked all mailbox stores and had no users (other than the system mailbox) in the stores. I looked up to the sky and screamed to the gods of Microsoft, why oh why do you make my life hell. But that's why we do it, because it's interesting and a challenge, not really, but whatever makes you sleep at night. So, there I was.... again. The solution was so simple that it almost evaded me.


The first part of the solution is as follows:

On your Excahnge 2003 server open ADUC, right-click your domain, and click find. Now click on the Exchange tab and select'Show only Exchange recipients' and click Find Now. If you have not already done so, show the column for Exchange Home Server by addig it to your list under View-> Choose Columns. Sort your results by the Home Server and note all users that show up on the server you are trying to remove and verify that these users either do not have a mailbox or have been moved to another server.


Part two involves using ADSI Edit. If you have not used this tool before, I strongly advise against using in a production environment. Load up a test DC and play around a bit first because you can really mess up your environment if you delete the wrong thing.

Launch ADSI Edit and Expand Domain NC. Locate the objects you took note of earlier and look at their properties. Navigate to the msExchHomeServerName and click edit. Now click clear and OK. This will remove the home server attribute from the user(s) in question.

Once those issues were resolved, the last Exchange 2003 server un-installed without a problem.

Thursday, March 5, 2009

Exchange 2007 Full Mailbox Access Rights

With PowerShell becoming more prevalent and in Exchange 2007, unavoidable, it was time for me to start using it for a change. There are many sites on the Internet that have a plethora of great examples and starting points. One I never found for Exchange that I finally did a trial and error on was how to give a user Full Mailbox Access to all mailboxes in the organization. As with PowerShell, one liners are great (for those who are new to PowerShell, a one liner is a single line of code that accomplishes many things). My one liner for Full Mailbox Access is below:

Get-Mailbox ¦ Add-MailboxPermission -AccessRights FullAccess -user 'user principle name'

In the above one-liner, it breaks down like this.

Get-Mailbox - This gets all mailboxes within your Exchange organization

Add-MailboxPermission - The mailbox acquired in the Get-Mailbox is piped to this command. The switches used are easy to follow.
The -AccessRights switch determines what rights you will give the user specified, options for this switch are: FullAccess, SendAs, ExternalAccount, DeleteItem, ReadPermission, ChangePermission, and ChangeOwner.
The -User switch just allows you to specify which user you wish to add the permission for.

This should make is easier for those who are not indoctrinated into Exchange 2007 to regain some measure of normality that you had while managing Exchange 2000/2003 or even 5.5.