1. Create a folder on your desktop called UMRA Backup, and then create 2 new files within that called UMRA and Resources.


2. Open up your UMRA console and select UMRA Service -> Manage service projects. Next Highlight all projects and folders, and press the button "Export", select "Yes" export to xml, and save these within your UMRA Backup/UMRA folder you created on your desktop?


3. Now that you have your UMRA projects successfully backed up, you now want to make sure any SQL database, VB Scripts etc. are backed up also. You would move these files / projects into the UMRA Backup/Resources folder?

4. Final step, is to now move the UMRA Backup folder to a secure file location?

So there you have it, a quick and easy way to backup your current UMRA projects. As always if you have any questions or comments feel free to email me, or leave a comment below.

1. Are the users already in Active Directory but not Google Apps?
* The reason why I ask this is because, when you create the Google Apps account, what will be the initial password upon creation? You can use any relevant data from either Active Directory, or another data source for the initial password.

2. Are the users that are going to be created in Google Apps, created in a specific container?
* Google Apps has the ability to create a container, much like Active Directories OU's. This is important because you need to know where to place a user upon creation, instead of putting everyone on the root. Having a clean

3. Are you going to keep your Google Apps users in sync with Active Directory?
* Creating accounts is only Google Apps is only one of the steps when doing a sync. Other standardization options include, location sync (what happens if a user moves schools after they are created in Google Apps), status sync (if a user becomes disabled in Active Directory, are you going to suspend in Google Apps), first name / last name sync (if the first or last name changes in Active Directory are you going to sync that into Google Apps).

4. Are you going to apply group memberships in Google Apps?
* Much like Active Directory, you can apply groups to users, however you will need to setup security on these groups. When setting up the security, you need to know who can send and use these group lists.

Those are 4 of the main questions I typically ask when doing a Active Directory to Google Apps sync. If you are able to answer these standard questions, or come up with your own standardization rules for these, doing the sync should be come a lot more easier to do. As always, if you have any questions or comments feel free to contact me, or leave a comment below.

'Create/Set Variables
Dim RetVal
Dim UMRA_Server
Dim UMRA_ Port
UMRA_Server = "MyServerName"
UMRA_Port = 56814
'End Create/Set Vairbales

Set Umra = Server.CreateObject("UMRAcom.Umra")
RetVal=Umra.Connect(UMRA_Server,UMRA_Port)
RetVal=Umra.ExecuteProjectScript(UMRA_Project)

When you run this script, you will see a "Return Value" if the value = 0 You were able to connect to the UMRA Server, and Run the Project you created, if you get a number other then 0, there was an error along the way. For now, this is the basics of how I connected to UMRA through the COM object.

Some other "Return Value" you might see are -5 and -1. -5 means the account that is trying to execute the UMRA form dosent have sufficent rights to run the project. You can the permissions on a UMRA from by selecting the forms properties, and clicking on the "security" tab. -1 mean either you couldnt connect to the UMRA service, or you had an error executing your UMRA project.

Now that should give you a good idea on hwo to connect to your UMRA service and execute a UMRA project through vbscript. If you have questions, please feel free to contact me or leave a comment below.

The fist thing you will need to do is figure out the connection method to your PowerSchool SIS. Typically there are 2 connection methods.

ODBC Connection - If you have a locally hosted PowerSchool SIS system, you can connect to the database and run a sql query, view, or stored proc to obtain the student or staff data.

.txt or .csv File - In some cases you wont have direct access to the Powerschool SIS system. In these cases the SIS is hosted remotely, so in this case you can either obtain a daily .txt or .csv file of the student or staff data.

Now, UMRA has both of these methods fully covered. UMRA uses a ODBC connection wizard to walk you through setting up the database connection string to your Powerschool SIS System. If you are only able to obtain a .txt or .csv UMRA is also able to read in these files, and display the data within them. Ok, so now that we have the data pulled within UMRA, I can now talk about some of the steps you can do with your UMRA automation.

Below is a typical sync I've done from Student data in PowerSchool to Active Directory.

Step 1 - Create a table of Active Directory Student Information
Step 2 - Create a table of Student data in PowerSchool
Step 3 - Join both AD and SIS data on a common key (username, student id etc.)
Step 4 - Based on this join, you will have 3 results (0,1,2)
Step 5 - Result 0 = Match in SIS and AD (compare user)
Step 6 - Result 1 = Record is in SIS data, but not AD (create user)
Step 7 - Result 2 = Record is in AD data, but not SIS data (retire user)

Below is a screen shot of how a UMRA project will look with some of the above steps. Keep in mind, we have no error logic added into our script, this can be added, but this is just an example of how it can look.

You can see, its an very easy process to figure out what student accounts within your student Powershcool data needs to either be created, compared, or disabled. Now that a defined process, we can go into more detail on what we can do on each of the result types. Now keep in mind that we are only going to go over the basics that I've seen in most UMRA automations.

In Detail Step 5 - Result 0 = Match in SIS and AD (compare user)
Since we have a match both in the Powerschool SIS data, and the AD data, we know that we can compare the data in both systems to see if anything has changed. An example of some of the common changes we've seen include, grade, school, status,name, or any other attribute you want to set and keep in sync with your SIS data.

In Detail Step 6 - Result 1 = Record is in SIS data, but not AD (create user)
Since a record shows up in your Powerschool SIS data but not Active Directory, we know we need to create the account in Active Directory. Upon the creation of an account, we can a lot of different procedures such as, setting group memberships, create home drives, map the user to a specific Active Directory OU, and even create a Google Apps Account.

Create Student Process Example Work Flow-
Step 1 - Create Account Active Directory
Step 2 - Apply Group Memberships based on school + grade etc.
Step 3 - Create Home Folder On Server + Setup Security on that folder
Step 4 - Create Google Apps Account

Just a small note on the Google Apps account. UMRA can do all the same actions you can do within your Google Apps admin console such as, creating an account, applying group memberships, suspend, unsuspend, even delete the account if needed.

In Detail Step 7 - Result 2 = Record is in AD data, but not SIS data (retire user)
Now this step can very depending on how you have your Powerschool data kick out displaying if someone has either withdrawn or graduated. In some causes the Student record just wont show up in the PowerSchool data anymore, or the status column could be a "w" or another flag to determine if the user is no long with the school district.
There are a lot of steps similar to the create, that we can do on the account that meets the specific flag. Below is an example of some of the steps UMRA can do.

Disable Process Example Work Flow-
Step 1 - Disable the account in Active Directory
Step 2 - Move the account in Active Directory to a Disabled OU
Step 3 - Suspend the Google Apps Account
Step 4 - Time / Date stamp the accounts description to say "Disabled by UMRA on 6/2/2011"
Step 5 - Check any Disabled Accounts to see if the account has been disabled for more the XX Days. If the account has been disabled for more then XX days.

Logging and Auditing
Some of you might be asking how does UMRA log the actions that it takes on object with Active Directory, or any other system. By default UMRA has a built in log, that logs every single action taken with any of the scripts performed with UMRA. On the other hand, you can also get a more details set of audit data. With most automation projects knowing what happened and what was changed in Active Directory is vital. So any actions that your UMRA projects performs, is recorded to a SQL database, or .txt / .csv file. UMRA can log out, date / time , who on, what attribute was changed, old value, new value, and any relevant notes on that action.

As you can see UMRA is a very powerful to automation and sync your Active Directory with PowerSchool student data. As always if you have any questions please feel free to email me, or leave a comment below.

Most live@edu implementations you will also need to have some type of "anchor" between the accounts in Active Directory, and your live@edu accounts. Sometimes you can use the actual email as the anchor, however using one of the live@edu attributes is another preferred method. Most of the time we will use a customattribute to store the EmployeeID, or StudentID from the HR or SIS system. This is a preferred method to ensure a permanent anchor between both the Active Directory account, and the live@edu account. Now, as you might know the customattribute field is stored in the "MailBox User" object, compared to the standard user data is stored in "User". So if you do the poweshell command below, you will notice you are unable to pull back the customattribute field.

Powershell Command -
Get-User -ResultSize Unlimited | windowsemailaddress -like '*your_user*' 

You will also notice if you run the below powershell command on the "Mailbox" object, you will be unable to get some of the data stored in the "User" object side.

Powershell Command -
Get-Mailbox -ResultSize Unlimited | windowsemailaddress -like '*your_user*' 

So how do you get around having to run 2 powershell queries to get a complete set of data you need from a user? Well you can write a powershell script like below. Let me explain what the script is doing first. First we do a filter on live@edu users "User" object to get a set of users who meet your filter criteria. Next, we loop through those the live@edu set of users, and grab any attributes needed on the "Mailbox" object side.

Powershell Command -
Get-User -ResultSize Unlimited | Where { $_.RecipientType -eq 'UserMailbox' -and $_.windowsemailaddress -like '*student*'  } | ForEach { $Users = @{} } { $Users[$_.SamAccountName] = $_ }
Get-Mailbox -ResultSize Unlimited | Where { $Users[$_.SamAccountName].Title -like '*student*' } |
  ForEach {
    New-Object psobject |
    Add-Member -PassThru NoteProperty Alias $_.Alias |
    Add-Member -PassThru NoteProperty FirstName $Users[$_.SamAccountName].FirstName |
    Add-Member -PassThru NoteProperty LastName $Users[$_.SamAccountName].LastName |
    Add-Member -PassThru NoteProperty windowsemailaddress $Users[$_.SamAccountName].windowsemailaddress |
    Add-Member -PassThru NoteProperty CustomAttribute1 $_.CustomAttribute1 |
}
  }

With the command above you can now access both "User" and "Mailbox" objects with just one powershell call. If you want to add additional attributes to the statement, just add another "Add-Member" option with your specific criteria to the powershell statement. Overall, the powershell method above is a quicker and more efficient way to pull data from your live@edu enviroment without having to run multiple powershell commands to get a users set of data.

Now that you have everything setup, you can create a test UMRA project to pull all of this together. Start off by opening up your UMRA console, and creating either an UMRA Automation Project or a UMRA MASS Project .

Drag and drop the UMRA actions below, into your UMRA project.


Run your script, and check for any errors. If your running this test with a UMRA MASS Project then you should see a window like below.


Now you should be ready to simply drag and drop or copy and paste your test UMRA project above into your production UMRA scripts. As always, if you have any questions feel free to comment below, or use the "contact me" main menu option.

Some of you already know what a Dynamic Distribution Group (DDG) is, and some of you might not. So let me explain what a DDG is for those of you who don't. Unlike traditional Security Groups, or Distribution Groups in Active Directory, DDG give you the ability to create filters to determine who is part of the DDG without retaining a static list of user objects. For example, lets say in your live @ edu environment that contains staff and student accounts: however, you only want students at a particular school and grade to receive emails from a DDG called "Joes_HighSchool_Grade_5. With DDG's you can do this by filtering attributes on the live @ edu accounts, so for example a filter might be Title -eq 'Student Grade 5' -and Description -eq 'Joes High School' . This filter will dynamically show you a list of users who Title in live @ edu is equal to 'Student Grade 5' with a second filter of, live @ edu users with a description of 'Joes High School'. Now, if you wanted to add users to this DDG or remove them, all you have to do is make sure the user or users don't meet your filter criteria, so there is no need to maintain users of a group anymore. As you can see DDG's are very easy to configure, and maintain compared to normal Distribution Lists. Now just on a side note, you can also create DDG in Exchange 2007 SP1 / SP2 and Exchange 2010.

So let's get down to it, how to create a DDG in your live @edu environment with UMRA. Now, I know some of you might be saying "I don't see a way to create DDG's in my live @ edu admin control panel", you are correct. Currently, there are no options to create / manage / edit any DDG information via the live @ edu admin control panel, however you can create / edit / manage your DDG's via powershell cmd window.

1. So first thing's first, you will need to setup your UMRA project to connect to your live @ edu environment.
Blog post here -> How to get UMRA connect to their Live @ edu environment

2. UMRA 10.6 does not have built in actions to create / manage / edit DDG's at the moment; however you can create your own custom powershell scripts and import them into your UMRA Service. At first I would run the powershell scripts via the command window, before importing them in your UMRA Service, to ensure you have your syntax right.

3. Run the powershell command below to connect to your live @ edu environment. You should get a popup window to enter your live @ edu admin username /password.
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session



When you are done with your powershell session, run the below command, or your session will still remain in use. By default you can only have three concurrent connections open to your live @ edu environment.

remove-PSSession $session

4. How to create a DDG'
New-DynamicDistributionGroup -Name 'New Group Name' -PrimarySmtpAddress 'somewhere@mydomain.com' -RecipientFilter 'Your Filter'

5. How to view your newly created DDG
get-dynamicdistributiongroup 'New Group Name' | Format-List

When you use Format-List it will show you all options that you are able to set on your DDG, this comes in handy when you're trying to set / get specific attributes on this DDG.

There you have it, a quick and easy way to create a DDG in your live @ edu environment. However, there is one major part of a DDG you will be missing if this is all you've done on the security. So why is the security so important? Well, you will need to restrict access on who can use these DDG's. You wouldn't want someone such as student be able to reply to every at a school now would ya? So there is a way you can set the security on who can actually send to these groups.

There are a few ways you can restrict sending access to any DDG's you have set up. You can restrict access of who can't send to the DDG, or you can restrict access of who can send to the DDG. Restricting who can send to the DDG is far easier to maintain then who can't send to the DDG. There are a few pitfalls when it comes to setting up the security on a DDG. The main pitfall being you can add either live @ edu accounts, or external contacts into your DDG security, or you can add a live @ edu security groups into the DDG security. Where this might become a problem is, if you don't have users that you want to send to these DDG's as external contacts or live @ edu users, you can't add them to your security groups within live @ edu.

Let's assume you have all your users either as external contacts, or actual live @ edu users. First thing you need to do is go into your admin live @ edu console, and create a security group called ddg_security. Then add all the external contacts, or live users who you want to be able to send to DDG.

If you only have 1 DDG created, then you can run the command below, to set the group as the security for who can send to this DDG.
set-dynamicdistributiongroup 'Your DDG Name' -AcceptMessagesOnlyFromSendersOrMembers 'Your Live @ edu Security Group Name'

If you have multiple DDG's, and need to set the security group on them all without going to each of them, you can run the below command.
$ddgs = get-dynamicdistributiongroup 'your filter'
or if you want to get all DDG's
$ddgs = get-dynamicdistributiongroup -resultsize unlimited

foreach ($ddg in $ddgs) { set-dynamicdistributiongroup $ddg.name -AcceptMessagesOnlyFromSendersOrMembers 'Your Live @ edu Security Group Name'}

If you want to allow only a specific external contact, or live @ edu account to send to this DDG run the below command.
set-dynamicdistributiongroup 'Your DDG Name' -AcceptMessagesOnlyFrom 'Your Live @ edu Contact'

So there you have it, a quick tutorial on how to get DDG's setup in your live @ edu environment. Overall DDG's are a powerful option compared to standard Distribution Groups. However live @ edu dosen't provide a lot of options to manage / create / edit these within your live @ edu admin portal which makes it hard to oversee. In my next blog posts I will continue on my live @ edu examples, and show you have to pull users from live @ edu, as well as created users in live @ edu with UMRA.