PowerShell Module and SnapIn Checks

One of the companies that I do a lot of work for uses Office 365 and everything they do is in bulk. Going through the portal to do anything is time consuming for everyone so I have been writing PowerShell scripts to automate as much as possible. The most common thing that I found is that I have to load the following modules and snapin's almost every time I run a script or a command. So rather than opening up several PowerShell windows to accomplish this task, I just load all the modules in the one window and proceed from there.

Here is the script that I put in place for loading all the modules for the following products:

- Exchange 2010

- Active Directory

- MS Online (Office 365)

- Quest AD Tools

The script does a check first to see if you have the module/snapin already loaded. If so, then it will skip to the next one. If not, then it will load the module/snapin. 

# Exchange Module Check
write-host "Checking to see if the Exchange Management PowerShell is installed"
if ((get-pssnapin -name Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction SilentlyContinue | foreach { $_.Name }) -ne "Microsoft.Exchange.Management.PowerShell.E2010")
{
write-host Exchange Management PowerShell is not added to this session, adding it now...
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction SilentlyContinue
}
else
{
write-host Exchange Management PowerShell is good to go. -backgroundcolor black -foregroundcolor green
start-sleep -s 1
}
write-host
write-host


# AD Module Check
write-host "Checking to see if the Active Directory PowerShell module is installed"
if ((get-module -name ActiveDirectory -ErrorAction SilentlyContinue | foreach { $_.Name }) -ne "ActiveDirectory")
{
write-host ActiveDirectory Management PowerShell is not added to this session, adding it now...
import-module activedirectory
}
else
{
write-host Active Directory PowerShell module is good to go. -backgroundcolor black -foregroundcolor green
start-sleep -s 1
}
write-host
write-host



# Microsoft Online Module Check
write-host "Checking to see if the Microsoft Online PowerShell module is installed"
if ((get-module -name MSOnline -ErrorAction SilentlyContinue | foreach { $_.Name }) -ne "MSOnline")
{
write-host Microsoft Online Management PowerShell is not added to this session, adding it now...
import-module MSOnline
connect-msolservice -credential
}
else
{
write-host Microsoft Online PowerShell module is good to go. -backgroundcolor black -foregroundcolor green
start-sleep -s 1
}
write-host
write-host



# Quest AD Module Check
write-host "Checking to see if the Quest AD PowerShell module is installed"if ((get-pssnapin -name Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue | foreach { $_.Name }) -ne "Quest.ActiveRoles.ADManagement")
{
write-host Quest AD Management PowerShell is not added to this session, adding it now...
Add-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue
}
else
{
write-host Quest AD PowerShell module is good to go. -backgroundcolor black -foregroundcolor green
start-sleep -s 1
}

Powershell script to make a Lync 2010 "Hunt Group" from scratch

I am really trying to beef up on my Powershell so I decided to make a script that would make a Lync 2010 Hunt Group. There was a challenge that I had where I was required to make (10) Hunt Groups workflows, queues, and groups. They were to be the same settings, just different users and phone numbers. The thought of going through all the wizards for all the settings just made me want to cry, so I decided to put the big boy pants on and learn how to do this via Powershell. Here goes....

Let's start by identifying what systems we will need to touch.

- Exchange server for creating the users and voicemail Unified Messaging (UM)
- Domain Controller for setting the 'telephone' option in the users account attributes
- Lync server for creating the users, worflow, queues, and groups.

Now that we know the systems, let declare the order of operations.

1st - Exchange to create the user account ONLY. Voicemail will come later.
2nd - Domain Controller - telephone attribute
              -> This is necessary as Exchange uses this information to assign the SIP URI in the next step
3rd - Exchange - enable the voicemail (UM)
4th - Lync to finish the script

Since we know the order of operations, let's dive into the script. I found that Powershell is much like PHP in the fact that you are declare variables in the beginning to use later. One gotcha here is that you can't call variables that haven't been created yet (hard lesson learned here - more to come about that). Here are the variables that I used:

        $SetNumber = '1'
        $SetName = 'Johnny Smith'
        $SetAlias = 'jsmith'
        $SetUserPrincipalName = 'jsmith@domain.local'
        $SetSAMAccountName = 'jsmith'
        $SetFirstName = 'Johnny'
        $SetLastName = 'Smith'
        $SetPassword = 'Password'
        $SetDBStore = 'DatabaseStore01'
        $Telephone = '8005551212'
        $SIPResourceID = $SetAlias + '@domain.local'
        $SetInboxPermission = $SetAlias + ':\inbox'

This is a good time to go ahead and run the commands. They are a little confusing and overwhelming at first look, but I think if you read the command, you will really see the variables in there and it will make sense:

From the Exchange server:

Command:  
New-Mailbox -Name $SetName -Alias $SetAlias -OrganizationalUnit 'domain.local/OU/CHILD_OU' -UserPrincipalName $SetUserPrincipalName -SamAccountName $SetSAMAccountName -FirstName $SetFirstName -Initials '' -LastName $SetLastName -ResetPasswordOnNextLogon $false -Database $SetDBStore

From the Domain Controller (NOTE: We have to declare the "$SetAlias" again as we jumped to a new server):

Variable:   $SetAlias = 'jsmith'
Command: Set-ADuser -id $SetAlias -officephone $Telephone 



From the Exchange Server (don't have to declare the variables as we already have them):

Command:
Enable-UMMailbox -Identity $SetName -UMMailboxPolicy "UMDefault Default Policy" -SIPResourceIdentifier $SIPResourceID

***EXTRA BONUS COMMAND***


I like to set the permissions on the user to allow for everyone to be able to view their mailbox. IMO, this just saves headaches in the future of you allowing users specifically. Here are the commands:

        set-MailboxFolderPermission -id $SetAlias -user default -AccessRights reviewer

        set-MailboxFolderPermission -id $SetInboxPermission -user default -AccessRights reviewer

***END - EXTRA BONUS COMMAND***

From the Lync Server:
(Quick NOTE before we get too far. We have to declare more variables here as we have created the user and now we have to get more information that we could only get AFTER we the previous steps have been created)

Variables:

        $ServiceId = "service:ApplicationServer:server.domain.local"
        $GroupName = "Group 1"
        $QueueName = "Queue 1"
        $WorkFlowName = "Hunt Group 1"
        $PrimaryURI = "sip:8005551212@domain.com"
        $LineURI = "tel:+18005551212"
        $DisplayNumber = "+1 (800) 555-1212"
        $DistoList = "distrolist@domain.local"
        $VoiceMail = "sip:jsmith@domain.local;opaque=app:voicemail"
 
 
Commands:

1. Create the group:

Command: New-CsRgsAgentGroup -Parent $ServiceId -Name $GroupName -AgentAlertTime 20 -ParticipationPolicy Informal -RoutingMethod Parallel -DistributionGroupAddress $DistoList

2. Create the queue:

Additional Variables:  $Group = get-csrgsagentgroup -Name $GroupName
Command: New-CsRgsQueue  -Parent $ServiceId  -Name $QueueName -TimeoutThreshold 30 -TimeoutAction $ActionTO -AgentGroupIDList($Group.Identity)

3. Create the workflow:

Additional Variables:

        $Queue = Get-CsRgsQueue -Name $QueueName
        $ActionTO = New-CsRgsCallAction -Action TransferToVoiceMailUri -uri $VoiceMail
        $ActionWM = New-CsRgsCallAction -Action TransferToQueue -QueueID $Queue.Identity
        $NBACTION = New-CsRgsCallAction -Action TransferToVoicemailUri -uri $VoiceMail

Command:

        New-CsRgsWorkflow -Parent $ServiceId -Name $WorkFlowName -Description "Hunt Group 1" -PrimaryUri $PrimaryURI -LineUri $LineURI -DisplayNumber $DisplayNumber -Active $true -Anonymous $true -DefaultAction $ActionWM -NonBusinessHoursAction $NBACTION

Create the user in Lync for the voicemail

Attributes: $Username = "jsmith@domain.local"
Commands:  

enable-csuser -identity $UserName -registrarpool lyncserver.domain.local -sipaddresstype Emailaddress -sipdomain domain.local
        
set-csuser -identity $UserName  -enterprisevoiceenabled $true
        
Grant-CsVoicePolicy -policyname "Voice Policy Name" -Identity $UserName
The script is finished!!!! Now you can go into the Lync control panel and see the changes that you have made. Now the reason for this script, rinse and repeat. Just change the "VARIABLES" to meet your needs. Since this was 1 of 10 users accounts, I just changed it from #1 to #10.

Showing Advanced Features in Active Directory

I edit SPN's a lot with MS SQL server and I was sick of using ADSIedit so I found that the ADMINPAK for Windows 7 would allow me to edit the SPN's directly. Only problem is that you can't see the "Attributes" tab in Active Directory Users and Computers (ADUC) without turning on the advanced features. Here is how I turned them on:

1. Open Active Directory Users and Computers (Start -> Run -> type: dsa.msc -> Ok)

2. Click on "View" then check "Advanced Features"



Now you can see the "Attributes" tab as well as a lot of other tabs that make editing user profiles a lot easier for the lonely sys-admin.

Enabling Protected Security Groups (domain admins) in Lync 2010

After installing and getting my Lync 2010 server up and running I was ready to enable and add myself to the Lync server. I logged into the Admin Console for Lync and added myself with all the correct options. Then I clicked "Enable" and found this error:

"Active Directory operation failed on "domain controller". You cannot retry this operation: "Insufficient access rights to perform the operation"

What do you mean I don't have rights, I'm a Domain Admin for crying out loud!!!! So onto the troubleshooting my rights. I have rights in AD. Lync server can contact the domain no problem. Everything looked to be fine. Then I found that my user account was in a "Protected Security Group" by being a domain admin.

Due to some security features in Active Directory (explained here), when you add or make a change to a user that is in a "Protected Security Group" (i.e. Enterprise or Domain Admins) in Lync 2010, you have to change their security to:

"Include inheritable permissions from this object's parent"



Steps to change this setting:
1. Open Active Directory Users and Computers (ADUC)
2. Change to the domain controller that is close to the Lync server
3. Follow the steps in this article to enable advanced features
4. Open the properties of the user account that you are enabling
5. Click on the "Security" tab
6. Click on "Advanced"
7. Check the box highlighted above
8. "OK" all the way back to ADUC
9. Enable the user in Lync admin console

This will allow you to enable them in the Lync server. This also applies to Exchange and here is a technet article that explains this in more depth.