First of all, thanks to Danny Jessee for tons of information to succeed in this assignment.

If you don’t know, SharePoint 2010/2013 can authenticate against identy providers such as Windows Live ID, Google, Yahoo!, and Facebook like a charm with no coding using Windows Azure Access Control Service (ACS) using Claims Based Authentication.

I see this will drive adoption of websites and therefore makes them successful.

Prerequisites

• Facebook App, any app, check the Facebook Developers application
• A Facebook account integrated with the app you will do.
• A Windows Azure account with an ACS namespace created (these can be created using the Service Bus, Access Control & Caching section of the portal) This will be used to be our host for Claims Identity Providers
• SharePoint 2013 Farm. (can work with 2010)
• An X.509 certificate to be used by Azure ACS and SharePoint to digitally sign tokens (and explicitly trusted by SharePoint)

Facebook Application Steps

• Within the Facebook Developers application, click Create New App.   
• Give the app a Name and a Namespace. Click Continue.
• After passing the Captcha check, select Website with Facebook Login in the next screen and enter the URL to your Azure ACS Service Namespace (e.g., https://{your namespace}.accesscontrol.windows.net). Click Save Changes.
• Take note of the App ID and App Secret values that appear at the top of this screen. You will need to use these to configure Azure ACS to leverage this application. That’s all we need to do within Facebook!

Azure ACS Steps

Within Azure ACS, we must configure the following four things:

• Facebook as an Identity Provider.
• SharePoint as a Relying Party Application.
• Claims Rule Groups to determine how Claims are passed from the identity provider to the relying party application.
• The Token Signing Certificate that Azure ACS will use to prove that it is indeed the issuer of the SAML token that SharePoint receives.

Identity Provider

• From within your Azure ACS management portal (e.g., https://{your namespace}.accesscontrol.windows.net) and select Identity providers from the Trust relationships section in the left navigation. In the next screen, click Add.
• In the next screen, choose Facebook application and click Next.
• In the next screen, enter the Application ID and Application secret values from the Facebook application you created above. You should also provide a Display name (for use within the ACS management portal) and a comma-separated list of Application permissions (note that email is the only required permission to enable Facebook users to sign in to SharePoint). You can, however, request additional permissions to do lots of fun and exciting things. Those permission strings are defined here.
• You do not need to specify values for Login link text or Image URL unless you plan to configure more than one Azure ACS identity provider to use with SharePoint. If you have already configured your Relying party applications within Azure ACS, you may select them at the bottom of this screen. Otherwise, we will configure SharePoint as an RP in the next step.
• Press Save to save changes.

Relying Party Application

From within your Azure ACS management portal (e.g., https://{your namespace}.accesscontrol.windows.net) and select Relying party applications from the Trust relationships section in the left navigation. In the next screen, click Add.

In the next screen, provide a name for the relying party application (I often just use the fully-qualified domain name of my SharePoint web application) and choose to Enter settings manually. In the boxes below, enter the following values:

• Realm – URL of your SharePoint web application (note that a URN can also be entered here and, in many cases, is the preferred approach)
• Return URL – URL of your SharePoint web application + /_trust – this is the endpoint for SharePoint’s STS, which is where Azure ACS will send the SAML token it creates. The " /_trust " is very important, if you put only web application URL, in SharePoint you will have an error that token is not from a trusted issuer.
• Token format – SAML 1.1
• Token lifetime – enter a value greater than the default 600 seconds, I would say 3600

In the Authentication Settings section, select the Identity provider you configured above and choose to Create a new rule group. Under Token Signing Settings, choose whether to Use service namespace certificate (if you have already configured a certificate within Azure ACS) or Use a dedicated certificate if you would like to use a different X.509 certificate exclusively for this relying party application.

Click Save to save changes.

Rule Group

• From within your Azure ACS management portal (e.g., https://{your namespace}.accesscontrol.windows.net) and select Rule groups from the Trust relationships section in the left navigation. In the next screen, click Default Rule Group for {your web application}
• Note that no rules are added by default. Click Generate and select the identity provider you created above.
• Click Generate to generate Claims rules for the 5 values Azure ACS can obtain from a logged in Facebook user:

1. AccessToken – the Facebook Graph API access token
2. emailaddress – the email address associated with the user’s Facebook profile
3. expiration – the expiration date/time of the AccessToken granted above
4. name – the Facebook user’s display name
5. nameidentifier – the Facebook user’s unique profile ID (integer)

• Press Save to save the rules.
• Upload Token Signing Certificate
• If you haven’t already, you will need to configure Azure ACS to utilize an X.509 certificate to digitally sign the tokens it generates. Optionally, you can also specify certificates to use for token encryption and decryption. I generated a self-signed certificate using the makecert utility FOR DEMO. DO NOT DO THIS IN PRODUCTION! I then uploaded this certificate by going to the Certificates and Keys link under Service settings in the ACS management portal.
• Click Add to upload your certificate. This page allows you to specify where the certificate should be used, what type of certificate it is, and how to make it the primary token-signing certificate. It even includes the specific makecert command you need to run to generate a self-signed certificate (again, I cannot overemphasize how important it is that you NOT use a self-signed certificate in production!)

SharePoint 2013 Steps

New Web Application

• From SharePoint 2013 Central Administration, create a new web application. Should be Claims and Claims is the default.
• Make sure the host header matches the host header for the Return URL specified in the Azure ACS relying party application setup. Enable Integrated
• Windows Authentication with NTLM at this step. You’ll notice no Trusted Identity providers exist at this point.
• Create a new site collection at the root of the web application and choose a Windows identity for the primary Site Collection Administrator.
• Configure Azure ACS as a new Trusted Identity Provider
• In order to enable us to select Azure ACS as a trusted identity provider for the web application, we need to run some PowerShell. The script to run appears below.

$realm = "http://www.contoso.com"

$signinurl = "https://[your name space].accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=http%3a%2f%2fwww.contoso.com%2f"

$certloc = "C:\contoso.cer"

$rootcert = Get-PfxCertificate $certloc

New-SPTrustedRootAuthority "Facebook Azure ACS" -Certificate $rootcert

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Display Name" –LocalClaimType   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"

$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://www.facebook.com/claims/AccessToken" -IncomingClaimTypeDisplayName "Access Token" -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "Name Identifier" –LocalClaimType   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

$map5 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration" -IncomingClaimTypeDisplayName "Expiration" -SameAsIncoming

New-SPTrustedIdentityTokenIssuer -Name "Facebook" -Description "Facebook" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2,$map3,$map4,$map5 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

Keep in mind:

• Ensure the value for $realm matches the realm value used when creating the relying party application within Azure ACS.
• Ensure the X.509 certificate used here is the same as the token signing certificate used when creating the Relying Party application within Azure ACS.
• Ensure the value for $signinurl is set properly for your SharePoint web application.

Run this PowerShell script from the SharePoint 2013 Management Shell (as an Administrator). If you don’t see red text, then we are good to go

Return to the list of web applications in SharePoint 2013 Central Administration. Select the web application and press Authentication Providers.

Choose the appropriate zone and scroll down. Facebook should now appear in the list of trusted identity providers.

Select Facebook and press Save. You have now configured Azure ACS as a new trusted identity provider, and SharePoint knows it can trust SAML tokens signed with your Azure ACS token-signing certificate.

Set User Access Policy

• In order for the users to access your SharePoint 2013 site once they have authenticated via Facebook, we must grant them the appropriate level of authorization. To do this, I recommend setting a “Full Read” policy for all users who authenticate to SharePoint via our “Facebook” trusted identity provider. Start by selecting the web application in Central Administration and go to User Policy.
• Choose Add Users, then select the appropriate zone (All zones) and press Next.
• Select the address book icon beneath the Users text box to bring up the Select People and Groups dialog.
• Select All Users, then choose All Users (Facebook). Press Add to select the group.
• Check the box for Full Read in the permissions section and press Finish.
• The new policy is now displayed at the bottom of the list.

We are ready to test :)

Sign in to SharePoint 2013 with Facebook

• Navigate to the home page of the web application. The default sign in page will appear.
• Choose Facebook from the drop down list. The user will be redirected (through the Azure ACS portal) to a Facebook-hosted login page.
• Enter your Facebook credentials and press Log In. The first time a user attempts to log in to your SharePoint site with Facebook, he or she will be prompted to grant the Facebook application access to the user’s basic information and email address (this is based on the permissions we set up when we initially defined the Facebook identity provider in the Azure ACS management portal).
• Press Go to App. The user should be redirected back to Azure ACS, which then redirects the user back to SharePoint…logged in with Facebook credentials!
• Note the user’s display name is the email address associated with the user’s Facebook account. This is because we set EmailAddress as the IdentifierClaim in the PowerShell script we ran to configure Azure ACS as a trusted identity provider.

Brief of Steps

Setting up this integration requires configuration steps to be performed in three different places:

1. Within Facebook, an application must be created that supports “Website with Facebook Login.”
2. Within the Azure ACS management portal, a new Identity Provider (IP), Relying Party (RP) application, and Rule Group must be created to inform Azure ACS about: a. The Facebook application created above. b. The SharePoint environment to be configured with Azure ACS integration below.
3. Within SharePoint, we must create a new web application with Claims (in SharePoint 2013, Claims is the default authentication mechanism) and configure it to point to our Azure ACS setup as a Trusted Identity Provider.

You can use some codeplex webparts that requires this technique , http://facebookwebparts.codeplex.com/ 

Feel free to post any questions in the comments!

Active Directory Import (AKA Active Directory Direct Import – ADDI) is one of the new features in SharePoint 2013 allowing you to import users from active directory into your SharePoint User Profile Service Application.

Background

In SharePoint 2010, there was only one method allowing you to sync user profiles between your user repository and your SharePoint environment which was essentially a lightweight version of FIM.

With SharePoint 2013, there are now three methods that you to carry out the aforementioned sync operation.

• SharePoint Profile Synchronization (lightweight FIM)
• Active Directory Import
• External Identity Manager (C#)

While the focus of this article is Active Directory Import, the amount of enhancements that have been done especially with regards to the performance of lightweight FIM elicit mentioning.
One of the most important areas of enhancements is regarding how FIM retrieves data from BCS.

In SharePoint 2013, import operations from BCS are done as batches rather than one by one.
Furthermore, indexes were added to user properties that eliminated full table scans. A number of unused provisioning steps were also removed.
The end result? One piece of anecdotal evidence show that 300K users took less than 7 hours for a full import operation, previously it took nearly three weeks.

Active Directory Import

Active Directory Import allows you to import users from active directory into your SharePoint 2013 environment. The logical question would then be what are the pro and cons of ADI and when should I used it over FIM. The table below summarizes these points.

I now use ADI for any development/PoC environment. I would also highly recommend it for any production environment that leverages only AD DS and doesn’t require writing back to AD.

Great! How do I enable ADI?

Enabling ADI is done over essentially 4 steps. These 4 steps are done against an instance of the user profile service application with the exception of the first step.

1. Configure AD DS permissions.
2. Enable Active Directory Import
3. Configure the connection properties
4. Map the user properties between AD and UPSA

1. Configure AD DS permissions

In this step, you grant the security permissions (Replicate Directory Changes permission) to the account that SharePoint uses to connect to AD DS during profile synchronization.

Step by step instructions are provided here: http://technet.microsoft.com/en-us/library/hh296982.aspx (Grant Active Directory Domain Services permissions for profile synchronization in SharePoint Server 2013)

2. Enable Active Directory Import

In this step, we select ADI as the import mechanism for the user profile service application instance that we accessing.

1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
2. On the SharePoint Central Administration website, in the Application Management section, click Manage service applications.
3. On the Manage Service Applications page, click the User Profile service application name.
4. On the Manage Profile Service page, in the Synchronization section, click Configure Synchronization Settings.
5. On the Configure Synchronization Settings page, in the Synchronization Options section, select the Use SharePoint Active Directory Import option, and then click OK.

3. Configure the connection properties

The lightweight FIM component that comes with SharePoint 2013 stores its connection configuration in the Sync DB, however ADI stores its connection configuration in the profile DB and therefore on changing the sync mechanism from FIM to ADI the first time, you will need to configure the connection properties for ADI.
These properties include the credentials used to connect to AD DS (these should be the same credentials that were given the permissions in step 1) as well as which items to sync.

On subsequently switching between FIM and ADI the connection properties are retrieved for each respectively.

The complete steps for doing so are provided in “Configure profile synchronization by using SharePoint Active Directory Import in SharePoint Server 2013” http://technet.microsoft.com/en-us/library/jj219646.aspx

4. Map user properties between AD and UPSA.

In this step, you determine how the properties of SharePoint user profiles map to the user information that is retrieved from AD DS.

1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
2. On the SharePoint Central Administration website, in the Application Management section, click Manage service applications.
3. On the Manage Service Applications page, click the User Profile service application name.
4. On the Manage Profile Service page, in the People section, click Manage User Properties.
5. On the Manage User Properties page, right-click the name of the property that you want to map to a directory service attribute, and then click Edit.
6. To remove an existing mapping, in the Property Mapping for Synchronization section, select the mapping that you want to remove, and then click Remove.
7. To add a new mapping, do the following:
1. In the Add New Mapping section, in the Source Data Connection list, select the data connection that represents the directory service to which you want to map the user profile property.
2. In the Attribute box, type the name of the directory service attribute to which you want to map the property.
3. Click Add.
   
8. Click OK.
9. Repeat steps 5 through 8 to map additional properties.

Tips and Tricks

1. Each time you change the sync mechanism from FIM to ADI the user profile synchronization service is stopped. You will need to restart it if you have switched to FIM.
   
2. If you are mapping attributes and are using FIM, all of the attributes from AD are listed in the drop down box. However if you are mapping the attributes using ADI, you will need to type the attributes in the textbox. The drop down is still displayed, however empty. This is not an indication that there is something wrong with your security.
3. When setting up the connection details, you will be prompted for the FQDN, this doesn’t include the machine name. If you add the machine name to the FQDN you will be presented with a “No containers to display” error message.

It’s possible to reset your Windows Sever 2008 / R2 Domain Controller administrator password using your installation CD.

1. Restart your Windows server 2008 DC with the installation CD


2. Choose your language and click next

3. Select your partition and installation version and click Next

4. Click on Comm and Line Prompt

5. Change directory to the access the system 32 directory. Then your original C:drive is changed to D: or E: depending on the number of drive and partitions you have on that system.

6. Rename the file Utilman.exe to Utilman.exe.bak using the comm and Copy Utilman.exe Utilman.exe.bak.

7. Using Command Move Cmd.exe Utilman.exe to move CMD.exe file into Utilman.exe. Press O or Y to accept after that restart your Computer normaly

8. At the user logon screen, press a combination of Windows KEY+U, then the CMD.exe will appear. Type net user “Username””new password”;

Then your system Admin Password is reset. Please don’t forget to rename back Utilman. Exe ->Cmd.exe and Utilman.exe.bak-> Utilman.exe after getting back access.

A fundamental condition that I always encountered when gathering workflow requirement is to get the user's manager approval, a tedious amount of coding to connect to active directory retrieve user profile information, get his manager login name, pass it as a parameter to the workflow, create a custom task for the manager with a notification. 

SharePoint 2010 Designer to the rescue, you can do all the above in 15 clicks, with ZERO code involved. Just by doing the following:

1. Open SharePoint Designer 2010 and connect to your SharePoint site.

2. Click Workflows and select the workflow type you need, for this presentation I'll use reusable workflow with All content types as my scope. But this doesn't affect the following logic, the same steps applies for the List and Site workflows.

3. From the Workflow ribbon select Actions > Collect Data from User, you can also select assign a to-do task but collect action from user allows you to create a custom task for the manager

4. This will show you the Action in the workflow editor.

5. The action is constructed from three parts:
   1. The data, which is the custom task that will be collected
   2. This user, which in our case the manager
   3. Output to variable: collect. Collect is  the task ID which you can change it, use it to refer to the task when you need to pass a variable through this task.

6. Clicking on data will allow you to create the custom task by starting the task wizard, open the wizard and click Next.
7. You will need to specify a Task name, and you can also specify a description. For now lets call the task "Review Task". And click Next

8. Now you can Specify the Task custom field by clicking Add and select the field type, I will specify two field:
   1. Approved as a choice with Yes/No.
   2. Comment as a text area.

  9. Provide the choices values, and hit Finish

10. Now it should be looking like this, with both fields listed

11. After finishing creating the Task, the condition will change in the editor to reflect the task name.

12. Now to the Fun part, getting the user manager. Simply click this user, Select "Workflow lookup for a user...", and click Add

13. Now you need to specify data source, in other situation you will need to specify the active directory, create a connection and the rest of this headache. All you need to do now is to select "User Profile" from the end of the list.
14. This will display all the user profile attribute that you can select from, such as manager. Select "Manager" and specify the out as "login name". This will lookup for the user manager and return his login name as a parapater in order to assign the task for this user's manager

15. Find the list item section allows you to select the user which you need his manager approval. In our case we the manager for the user who started the workflow.  So I will select the Field as "Account Name" and click on the formula button in the value field.

 16. Specify the data source as workflow Context, the Field source is the Workflow "Current User" , and Return Field as "Login Name". Click OK, OK and OK.

 17. The Action should be looking like this now.

 



 

Voila, Now you have your custom task that will be sent to the user's manager with a notification in his task list.

 

Enjoy.

SEFAUtil

Abstract: SEFAUtil (secondary extension feature activation) is a command-line tool that enables Microsoft Lync Server 2010 communications software administrators and helpdesk agents to configure delegate-ringing and call-forwarding settings on behalf of a Lync Server 2010 user. The tool also allows administrators to query the call-routing settings that are published for a particular user.

The SEFAUtil tool allows the administrator to enable/disable/modify call forwarding on behalf of the user. The administrator can specify the target (in the form of a SIP URI) or use a target that has already been published by the user. This tool also allows administrators to add or remove delegates on behalf of the user. The tool supports enabling or disabling simultaneous ringing, delayed ringing, or call forwarding to delegates.

This tool is built on Microsoft Unified Communications Managed API (UCMA) 3.0 and requires that administrators create a trusted application in the Central Management store for SEFAUtil.

Introduction

SEFAUtil (secondary extension feature activation) enables Lync Server 2010 administrators and helpdesk agents to configure delegate-ringing and call-forwarding settings on behalf of a Lync Server user. This tool also allows administrators to query the call-routing settings that are published for a particular user.

Description

The current version of SEFAUtil is only a command-line tool; there is no supporting graphical user interface. This tool is based on Microsoft Unified Communications Managed API (UCMA) 3.0. The features in this tool allow administrators and helpdesk agents to do the following:

· View all call routing settings for a user (includes call forwarding, delegation, team ringing, and simultaneous ringing)

· Enable/disable/modify call-forwarding setting (includes destination and no-answer timer)

· Enable/disable/modify call-forwarding immediate configurations

· Enable/disable/modify delegation settings

This tool has the following limitations:

· Cannot configure team ringing

· Cannot configure simultaneous ringing

· Supported only for users homed in a Lync Server pool

· Bulk-edit of call routing settings for several users is not supported

Output

The current version of this tool provides output only in the Command Prompt window. For more information, see the “Examples” section later in this document.

Purpose

Following are some of the key scenarios where this tool may be used:

· Bob is an executive and has been moved to Microsoft Office Communications Server telephony. He has delegation on his existing PBX system. As part of the move to Office Communications Server, the administrator is able to configure Bob’s routing to reflect his pre-existing delegation configuration.

· Alice is travelling and realizes that she is expecting an important call from one of her customers. However, she is in a hotel and has no access to a computer. She calls the helpdesk and requests that they forward to her mobile number all the calls made to her work number. The helpdesk personnel are able to do the configuration on her behalf.

· Joe’s calls to his work number are going to his mobile voicemail whenever he is at work; however, things appear to be working correctly in most other locations. The helpdesk technician is able to view Joe’s routing configuration and discovers that Joe has simultaneous ringing configured to his mobile phone. The technician asks Joe about the mobile coverage at his office and is able to determine that the simultaneous ringing rule is what is causing the calls to go to Joe’s mobile voicemail when his network coverage is poor.

Requirements

The SEFAUtil tool can be run only on a computer that is a part of a Trusted Application Pool. UCMA 3.0 must be installed on that computer. To run the tool, a new Trusted Application with the sefautil application ID must be created on that pool.

Examples

Display Current Call Handling Settings

The following command displays the call handling for the user.

Note This example uses the /server switch to specify the Lync Server to connect to.

SEFAUtil.exe /server:lyncserver.contoso.com katarina@contoso.com

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Simulring enabled: False

User Ring time: 00:00:20

Call Forward No Answer to: voicemail

Set the Call Forward/No Answer Destination

This example sets the call forward/no answer destination and the ring delay. Here, the /server switch is not provided; SEFAUtil attempts to autodiscover the Lync Server.

SEFAUtil.exe /server:lyncserver.contoso.com sip:katarina@contoso.com /enablefwdnoanswer /callanswerwaittime:30 /setfwddestination:+1425555 0126@contoso.com;user=phone

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Simulring enabled: False

User Ring time: 00:00:30

Call Forward No Answer to: sip:+14255550126@contoso.com;user=phone

Enable Call Forwarding Immediately

This example immediately enables call-forwarding to another user.

SEFAUtil.exe sip:katarina@contoso.com /enablefwdimmediate /setfwddestination:anders@contoso.com

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Simulring enabled: False

Forward immediate to: sip:anders@contoso.com

Disable Call Forwarding Immediately

This example immediately disables call forwarding.

SEFAUtil.exe /server:lyncserver.contoso.com katarina@contoso.com /disablefwdimmediate

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Simulring enabled: False

User Ring time: 00:00:30

Call Forward No Answer to: voicemail

Add a User as a Delegate and Set Up Simultaneous Ringing of Delegates

This example adds a user as a delegate and sets up simultaneous ringing of delegates.

SEFAUtil.exe /server: lyncserver.contoso.com sip:katarina@contoso.com /adddelegate:joe@contoso.com /simulringdelegates

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Simultaneously Ringing Delegates: sip:joe@contoso.com

Change Simultaneous Ringing Rule

This example changes the simultaneous ringing rule that was set in the previous example to the delayed ringing rule.

SEFAUtil.exe /server: lyncserver.contoso.com sip:katarina@contoso.com /delayringdelegates:10

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Simulring enabled: False

Delay Ringing Delegates (delay:10 seconds): sip:joe@contoso.com

Remove the Delegate

This example removes the delegate.

Note When the last delegate is removed, delegate ringing is automatically disabled.

SEFAUtil.exe /server: lyncserver.contoso.com sip:katarina@contoso.com /removedelegate:joe@contoso.com

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Simulring enabled: False

User Ring time: 00:00:30

Call Forward No Answer to: voicemail

Add a Delegate and Set Up the Call-Forward to Delegates Rule

This example adds a delegate and sets up the call-forward to delegates rule.

SEFAUtil.exe /server: lyncserver.contoso.com sip:katarina@contoso.com /adddelegate:anders@contoso.com /fwdtodelegates

Output

User Aor: sip:katarina@contoso.com

Display Name: Katarina Larsson

UM Enabled: True

Forwarding calls to Delegates: sip:anders@contoso.com

Summary

SEFAUtil addresses some of the core scenarios that surround secondary extension feature activation. SEFAUtil also allows administrators to monitor/view call-routing configuration and to modify some of the essential elements like call forward/no answer, call forward unconditional, and delegation.