Section 1: Prepare Environment - Step 1: Prepare Active Directory.

By -

Section 1: Prepare Environment

Step 1: Prepare Active Directory.

Firstly we will prep the schema. Ensure you meet the prerequisites; mainly the user must be a member of the Schema Admins group in AD. Click on Run to start.

Click Next at the welcome splash screen, in most installs you will edit the default schema so click Next here to the default.




Click Next to start Schema Prep. When done click Finish.

(We got a warning here but this is ok as I had forgotten to raise schema level...Doh!! Always read the prerequisites. - Active Directory MUST be running in 2003 Native Mode or higher - Mixed Mode is not supported and will not work!!!)

Step 1.2: Verify replication 

Verifying Replication of Schema Preparation

After you prepare the schema but before you continue to Prep Forest, you must wait for Active Directory Domain Services replication to complete, or you can force replication to all the domain controllers that are listed in the Active Directory Sites and Services snap-in for the forest root domain controller. 


To verify replication of the schema extensions for Office Communications Server, follow these steps.

 
 
This step is a manual task:

 

 

 

 


To verify replication of schema preparation:

  • Ø  Insert the Microsoft Office Communications Server installation media.
  • Ø  Click Start, and then click Run. In the Open box, type cmd, and then click OK.
  • Ø  At the command prompt, change to the CD drive, and then navigate to the \Setup\amd64 folder.
  • Ø  At the command prompt, type LcsCmd /Forest /action:CheckSchemaPrepState /PDCRequired:FALSE, and then press ENTER.
  • Ø  After execution is complete, open the HTML log file that was created by the command.
  • Ø  In the log, expand Execute Action.
  • Ø  Next to Check Schema Prep State, verify that the result for Schema Prep State is the version of the server that you currently have installed and that appears under the Execution Result column.

The CheckSchemaPrepState task queries a random domain controller in the root domain other than the primary domain controller to verify that the correct version of the Office Communications Server schema has been uploaded to that domain controller.

 Note   For an alternate procedure for verifying schema replication, see Preparing Active Directory Domain Services for Office Communications Server 2007 R2.

When we done this the following was output:


This completed successfully and shows us where it created a log file for us to view.

LOG FILE: - All Success


Step 1.3: Prep Forest.

Next we will prep the forest:



Click Next at the splash screen, we will store the global settings in the Configuration Partition (Recommended) – OCS R1 and LCS 2005 stored settings in System Container, if you are upgrading you should move these first.

Although it is marked as "optional" before upgrading to OCS 2007 R2, it is highly recommended to migrate the global settings to the Configuration container for a few important reasons. 

The primary reason is that if you upgrade your Active Directory schema to OCS 2007 R2 before moving the global settings container contents to the configuration partition, you can no longer use the MigrateOCS.vbs script. You will be "stuck" with those settings moving forward. 

The other reasons are primarily performance related, which the documentation for OCS 2007 R2 goes over. 

To quote a section of the documentation:

In previous versions of Office Communications Server, the default container was the root domain System container. Although storing global settings in the System container has advantages, such as faster replication and fewer replicated copies, in centralized topologies, this approach might not perform as well in geographically distributed topologies if root domain availability is insufficient. It can also cause long service start time or long replication delays when you manage global settings.
The actual documentation for MigrateOCS.vbs can be, honestly, a little confusing. I used the LCSCMD.EXE from OCS 2007 R1 to make sure that I wouldn't accidentally put R2 specific entries into Active Directory. 

Before performing the actual deletion of the RTC Service tree from the System container of Active Directory, I took a snapshot of the LDAP entries in DN: 

CN=RTCService,CN=Microsoft,CN=System,DC=mgdomain,DC=ie

The command I used was ldifde -f SystemContainerBackup.LDF -d "CN=RTCService,CN=Microsoft,CN=System,DC=mgdomain,DC=ie

Of course, replace mgdomain and ie with your actual domain information. 

I also took a backup of the OCS setup into an XML file using:
lcscmd.exe /config /action:export /level:global,machine,pool /configfile:OCSBackup.xml /poolname:mgocspool01

Why did I do this? The MigrateOCS script does not provide a back out procedure. If things really went south, I wanted a tangible way to restore my environment. (thanks to - http://blog.tiensivu.com/aaron for this section above on migrating)

Click Next and then choose the Domain which will house the Universal groups from the drop-down list and click Next.



Now we select our SIP domain (usually the same as our email domain e.g. @mgdomain.ie) and click Next, now review the settings and click Next, when done you can review the log and press Finish.



Step 1.4: Verify Replication of Global Settings and Global Catalog

 This is a manual task and should be checked if you use multiple Domain Controllers/GCs. Ensure replication before continuing.

Step 1.5: Prep Current Domain

 Now we need to run our Domain Prep. We must ensure we run this as a Domain Admin and that our Domain is running in Windows 2003 Native Mode or higher.


Click Run to start the Domain Prep. This creates relevant groups needed for OCS install and running.



Click Next at the splash screen, review the description and click Next, review what is about to happen and click Next


When completed we have option of reviewing Log and click Finish.

Step 1.6: Verify Replication in Domain.
This is a manual task and should be checked if you use multiple Domain Controllers/GCs. Ensure replication before continuing.




Above is the output from our verification of Domain Replication. All is successful and a log is available to view.

Step 1.7: Delegate Setup and Administration

Step 1.7.1:  Delegate Setup Tasks

Click Run under Delegate Setup Tasks and then click Next at the Splash Screen.



Now we select the Trustee domain from the dropdown list and name the existing group in AD for delegates. Click Next.

For next step we need full Distinguished Name path to the FE server, we can get this through ADSIEDIT.msc.

Our example is: CN=MGOCSFE01,OU=OCS-Servers,DC=mgdomain,DC=ie           and click Next



Now we specify a SIP Service Account  and Component Service Account to use (both set up as prerequisite). Click Next.

We use RTCService and RTCComponentService accounts (Default naming for OCS)


Once completed review log and click Finish.

Step 1.7.2: Delegate Server Administration:

This is a manual task.

Ensure your administrator account is part of RTCUniversalServerAdmins group.

http://technet.microsoft.com/en-us/library/dd425312(office.13).aspx

http://i.technet.microsoft.com/Global/Images/clear.gif To delegate server administration

  1. Log on to a computer in the domain where you want to grant permissions. Use an account that is a member of the RTCUniversalServerAdmins and DomainAdmins groups or that has equivalent user rights.
  2. Open a command prompt and then type the following command:

LcsCmd /Domain[:] /Action:CreateDelegation

/Delegation:ServerAdmin /TrusteeGroup:

/TrusteeDomain:

/ServiceAccount:

/ComponentServiceAccount:

/ComputerOU:

/PoolName:

[/ExtraServers:]

Where:

TrusteeGroup is the group to which you are granting permissions.

TrusteeDomain is the domain in which the trustee group resides.

ServiceAccount is the Real-time Communications (RTC) service account name.

ComponentServiceAccount is the RTC component service account name.

ComputerOU is the distinguished name (DN) of the OU containing the computer running the server to which you are granting administrative permissions.

PoolName is the name of the Standard Edition server or Enterprise pool in which the trustee group can administer servers; adds the trustee group to the Local Administrators group of each computer in the pool to the AdminRole of the RTC database, and to the ReadWriteRole of the RTCConfig database on the SQL Server back-end database server.

ExtraServers is a comma separated list of fully qualified domain names (FQDNs) of computers that are not part of a pool to which the trustee group requires access. You can enter the FQDN of Archiving Servers, Monitoring Servers (that is, Call Detail Recording (CDR) and Quality of Experience (QoE)), Mediation Servers, or the internal FQDN of edge servers (that is, if the edge servers are domain edge servers; if they are in a workgroup, they cannot be delegated).

LcsCmd /Domain:mgdomain.ie /Action:CreateDelegation /Delegation:ServerAdmin /TrusteeGroup:RTCSetupDelegate /TrusteeDomain:mgdomain.ie /ServiceAccount:RTCService /ComponentServiceAccount:RTCComponentService /ComputerOU OU=OCS-Servers,DC=mgdomain,DC=ie /PoolName:mgocspool.mgdomain.ie

 
 
Our example is:

 

 

 

 

Below is our output, again with a log location.


Step 1.7.3: Delegate User Administration:

This is a manual task.


To delegate user administration

  1. Log on to a computer in the domain where you want to grant permissions. Use an account that is a member of the DomainAdmins groups or that has equivalent user rights.
  2. Open a command prompt and then type the following command:

LcsCmd.exe /Domain[:] /Action:CreateDelegation

/Delegation:UserAdmin /TrusteeGroup:

/TrusteeDomain:

/ServiceAccount:

/ComponentServiceAccount:

/ComputerOU:

/UserOU:

/UserType:{User | Contact | InetOrgPerson}

/PoolName:

Where:

TrusteeGroup is the group to which you are granting permissions.

TrusteeDomain is the domain in which you are granting permissions.

ServiceAccount is the Real-time Communications (RTC) service account name.

ComponentServiceAccount is the RTC component service account name.

ComputerOU is the distinguished name (DN) of the OU containing the computer running the Office Communications Server Front End Server that hosts the users the trustee group will administer. The OU that is specified by the/Computer OU parameter and the OU that is specified by the /UserOU parameter must reside in the same domain. If you want to delegate the administration of users in a domain other than the domain where Office Communications Server is installed, the organizational unit that is specified by the /Computer OU parameter still must reside in the same domain as the OU that is specified by the /UserOU parameter.

UserOU specifies the DN of the OU containing the users that the trustee group will administer. The OU that is specified by the /Computer OU parameter and the OU that is specified by the /UserOU parameter must reside in the same domain.

UserType is the type of user object that the trustee group will have permissions to administer. Valid values are User, Contact, or InetOrgPerson.

PoolName is the name of the Standard Edition server or Enterprise pool in which the trustee group can administer users, and adds the trustee group to the Local Administrators group of each computer in the pool and to the ReadOnlyRole of the SQL Server back-end databases.

Our example is:

LcsCmd.exe /Domain:mgdomain.ie /Action:CreateDelegation /Delegation:UserAdmin /TrusteeGroup:RTCSetupDelegate /TrusteeDomain:mgdomain.ie /ServiceAccount:RTCService /ComponentServiceAccount:RTCComponentService /ComputerOU: OU=OCS-Servers,DC=mgdomain,DC=ie /UserOU: CN=Users,DC=mgdomain,DC=ie /UserType:User /PoolName:mgocspool.mgdomain.ie

 
 
 

 

 

 

 

Below is our output, again with a log location.




Step 1.7.4: Delegate Read-Only Office Communicator Server Administration:

This is a manual task.

http://i.technet.microsoft.com/Global/Images/clear.gif To delegate read-only server administration

  1. Log on to a computer in the domain where you want to grant permissions. Use an account that has RTCUniversalServerAdmins and DomainAdmins or equivalent user rights.
  2. Use the following command:

LcsCmd /Domain[:] /Action:CreateDelegation

/Delegation:ReadOnlyAdmin /TrusteeGroup:

/TrusteeDomain:

/ServiceAccount:

/ComponentServiceAccount:

/ComputerOU:

/PoolName:

[/ExtraServers:]

Where:

TrusteeGroup is the group to which you are granting permissions.

TrusteeDomain is the domain in which you are granting permissions.

ServiceAccount is the RTC service account name.

ComponentServiceAccount is the RTC component service account name.

ComputerOU is the distinguished name (DN) of the OU containing the computer running the server to which you are granting the trustee group read-only administrative permissions.

PoolName is the name of the Standard Edition server or Enterprise pool in which the trustee group can perform read-only server administration, and adds the trustee group to the Local Administrators group of each computer in the pool and to the ReadOnlyRole of the SQL Server back-end databases.

ExtraServers is a comma separated list of fully qualified domain names (FQDNs) of computers to which the group requires access but which are not part of the pool. You can enter the FQDN of Archiving Servers, Monitoring Servers (that is, Call Detail Recording (CDR) and Quality of Experience (QoE)), Mediation Servers, or the internal FQDN of Edge Servers (that is, if the Edge Servers are domain Edge Servers; if they are in a workgroup, they cannot be delegated).

Our example is:

LcsCmd /Domain:mgdomain.ie /Action:CreateDelegation /Delegation:ReadOnlyAdmin /TrusteeGroup:RTCSetupDelegate /TrusteeDomain:mgdomain.ie /ServiceAccount:RTCService /ComponentServiceAccount:RTCComponentService /ComputerOU:OU=OCS-Servers,DC=mgdomain,DC=ie /PoolName:mgocspool.mgdomain.ie

 

 
 

 

 

 

 

Below is our output, again with a log location.



Now back to Step 2: (Create Enterprise Pool)

Comments

Post a Comment

Popular posts from this blog

Teams Device Health Monitoring and Reporting

By -
Image
 Microsoft have snuck in a nice new feature into the Teams Admin Center (TAC). We now see a new Notifications and Alerts  menu tree and below this Rules. When we go in here, we find only a single Default  Device State Rule with no option to create any new rules (yet at least...) When we edit this rule, we can see that we now have an option to monitor specific devices (think meeting room devices, collaboration bars etc.. here) Under Device users  we click on +ADD  then enter the name of the account, or accounts if you are monitoring multiple devices, associated with the device, such as the resource account. Then under Actions  we can choose either Channel alert  - to have a nice alert sent to our Teams Channel   OR Webhook  to use webhooks for alerting. Finally ensure to select Active  then Save. Once set up this will take maybe 15 mins to replicate and set up. Then once a device has gone offline, the alert will be sent "Immediately", however it seems to take between 5-10 mins
Read more

Unassigned Numbers in Microsoft Teams using Audiocodes SBC

By -
Image
Unlike Skype for Business, Microsoft Teams does not natively support the handling of Unassigned numbers in the system. So if someone leaves your organisation and you remove the number from them and someone tries to call it, the call will drop. Technically, Teams will return a "404 Not Found" back to the SBC and back on to the telco. What we can do here is to then assign the 404 error to a Route, change the Destination Number (to a call queue or to your main Reception number for example) and route it back to Teams. To do this there are a few simple steps: Step 1 – Create an Alternative Reasons Set Step 2 – Configure existing Teams IP Group to use the SBC Alternative Routing Reason Set Step 3 - Create new IPG Step 4 – Create a new route in IP-to-IP Routing Step 5 - Manipulate Numbers Step 6 – Test  Step 1 – Create an Alternative Reasons Set The first thing we need to do is create an " Alternative Routing Set ", we find this under Setup >> Signaling & Media &
Read more

Skype for Business Edge Server replication troubleshooter

By -
Image
Many times in Skype for Business/Lync the main issue I come across is the deployment is that the edge server(s) fails to replicate. We see this when we run the command in Skype for Business Management Shell : Get-CsManagementStoreReplicationStatus and we see that the edge servers have False and no LastStatusReport or ProductVersion is shown as below. There are a number of things which can cause this and I am going to list them here. Try them in order here as this will contain the most common to the least common issues I found. Ø   Routing Ø   Firewall rules Ø   DNS suffix Ø   DNS (Local and LAN) Ø   Registry entries for SCHANNEL Ø   Certificates A check we can use to see if the replication is working can be done by trying to connect to the following URL from the Front End Server whish hosts the CMS: https://edgeinternalfqdn.domain.ie:4443/Replicationwebservice You should get the following screen: Without this response there is an issue,
Read more