Exciting System Center 2012 Features

A couple weeks ago, I had the opportunity to visit Microsoft and see, first hand, some of what System Center 2012 has in store for us. For the first time, System Center components have been truly integrated, providing some unique and powerful automation capabilities.

What if Configuration Manager could automatically respond to, and remediate, an error or warning event detected by Operations Manager? What if a request for a software installation in Service Manager could be automatically carried through an approval process leading to the application being installed by Configuration Manager? What automatic virus infection remediation? Client data protection? System Center 2012 can do it all.

Still, there are a couple features that I’m really excited about, and I think warrant a little more attention.

First is Configuration Manager’s shift to a user-oriented architecture, which allows application installs to be targeted at users, not just computers. It also presents available applications based on who is searching, not which computer he or she is using. This change can really make an administrator’s life easier. We can focus on who needs access to things, rather than which device provides access (and who is in possession of that device). The new Configuration Manager bridges the gap between user and app, creating an easier administrative experience and a superior user experience.

The other feature is Operations Manager ability to monitor, natively, web apps (.NET and J2E, specifically). Operations Manager can not only inform you if your application is unavailable, it can also alert you to performance issues within the application itself. Additionally, the Operations Manager dashboard allows an administrator to delve from a physical host server, into a virtual machine, and then into web services and specific web sites and applications to identify problems within a single interface. Operations Manager can greatly simplify monitoring your systems and infrastructure and shorten time to resolution.

System Center 2012 offers many, many more capabilities as well. Hopefully, this has helped whet your appetite, as the official release is right around the corner!

Shane Skriletz, PEI

How to Backup Lync (Part 1)

A question that I am frequently asked after we get Lync installed and running is “How do we backup Lync?” This is a great question and one that is easy to answer. Thanks to the Central Management idea and Topology Builder, we only have to backup a few items in order to get the entire Lync environment backed up.

There are two crucial pieces for most environments. First is the topology itself and then secondly, we need the user’s data (Contacts, etc). To do the first piece, we use Export-CsConfiguration from the Lync Management Shell. An example:

Export-CsConfiguration -FileName MyTopologyBackup.zip

To backup the users data, we need to use the dbimpexp.exe tool. This tool is available in the root folder of the Lync Server installation media. It is also installed at \Program Files\Common Files\Microsoft Lync Server 2010\Support as part of the Core Components. Here is an example of how to run the dbimpexp.exe command:

Dbimpexp.exe /hrxmlfile:<path and backup file name> /sqlserver:<SQL Server FQDN>\<instance name>

dbimpexp.exe /hrxmlfile:MyUserDataBackup.xml /sqlserver:mysqlserver.domain.com

With these two pieces you can get most of your Lync environment. In the next article I will detail how to backup other Lync components such as the Location Database, Group Chat and Response Group settings.

Adam Ball, PEI

Microsoft Project – Fixed Duration, Fixed Units and Fixed Work

One of the more difficult scheduling aspects in using Microsoft Project to schedule effort driven work is the concept of Fixed Duration, Fixed Units and Fixed Work. I have heard numerous colleagues including myself at times say “what’s wrong with Microsoft Project, its changing the schedule in crazy ways when resources are added or subtracted”. In fact, Microsoft Project is functioning correctly once one understands the way fundamental way it works.

Microsoft Project, when scheduling tasks based on effort driven schedules allows the project manager to work with three different variables. The project manager can only control two of these variables while Microsoft Project always automatically calculates the third. These variables are:

1. Fixed Units

2. Fixed Duration

3. Fixed Work

It is critical for a project manager to have a comprehensive understanding of the implications of each of these variables.

Fixed Units suggests that are the amount of capacity that a resource can devote to a task. An example of this is that you suggest to Microsoft Project that a resource can only work 50% of the time on a specific task. Microsoft Project will then automatically calculate the duration of the task with the resource only working 50% of the time.

Fixed Duration suggested that the task the task must be completed within a given duration. As you assign a single or multiple resources to the task, Microsoft Project will automatically calculate the appropriate resource allocation percentage to ensure the task is completed within the given duration.

Fixed Work suggests that a task has a specific numbers of hours work associated with it. In this scenario, we know that the task is going to take ten hours to complete. We have the ability to schedule the tasks overall duration for five days with fixed work of ten hours. Assuming a single resource is responsible for completing the task, Microsoft Project will schedule the resource to work two hours a day for the five day duration.

There are several advanced scheduling scenarios that can influence what is discussed above including front, middle and back loading of resources which aren’t addressed in this blog. For more information on this topic, I recommend the following from the Microsoft Website: http://office.microsoft.com/en-us/project-help/using-task-types-RZ001077906.aspx?section=6

Dan Thompson, PEI

Microsoft Exchange 2010 – Using Proxying and Redirection (Part 2)

Cross-Site Silent Redirection

Exchange 2010 SP2 lets administrators configure cross-site silent redirection. When this feature is enabled, a user with a mailbox in Active Directory site A who accesses the Outlook Web App URL in Active Directory site B will be silently redirected to the Outlook Web App URL for Active Directory A.

To configure cross-site silent redirection, the administrator must use the new CrossSiteRedirectType parameter that’s been added to the Set-OWAVirtualDirectory cmdlet. The parameter has two possible settings. The default setting is Manual.

• Silent When this setting is configured, a user’s web browser is automatically redirected whenever a Client Access server must redirect an Outlook Web App request to Client Access server or server array located in another Active Directory site. If you’re using forms-based authentication, SSL is required. For redirection to occur, the target Client Access server Outlook Web App virtual directory must have an ExternalURL value configured.

• Manual When this setting is configured, users will receive a notification that they’re accessing the wrong URL and that they must click a link to access the correct Outlook Web App URL for their mailbox. This notification only occurs when a Client Access server determines that it must redirect an Outlook Web App request to Client Access server or server array located in another Active Directory site. For redirection to occur, the target Client Access server Outlook Web App virtual directory must have an ExternalURL value configured.

Cross-site silent redirection prevents users from having to learn a secondary Outlook Web App URL. If the authentication method for the Outlook Web App virtual directory on both the source and target Client Access servers is set to forms-based authentication, the user will only have to enter their credentials once. If the authentication methods differ on the source and target Client Access severs, the users may have to enter their credentials a second time. When using forms-based authentication, you must require SSL on both the source and target Outlook Web App virtual directories.

Proxying and Redirection for Exchange ActiveSync

The following series of steps shows how incoming requests are handled for a user who connects to an Exchange 2010 Client Access server named CAS-01 using a mobile phone.

1. The Client Access server queries Active Directory to determine the location of the user’s mailbox and the version of Microsoft Exchange installed on the Mailbox server.

2. If the user’s mailbox is on an Exchange 2003 server, the incoming request is proxied directly to the Exchange 2003 server that hosts the user’s mailbox and the Exchange ActiveSync virtual directory. By default, in Exchange 2003, the Exchange ActiveSync virtual directory was installed on all mailbox servers. The Active Directory site of the user’s mailbox isn’t applicable in this case because Exchange 2003 doesn’t use Active Directory sites to determine location. The connection is always made directly from the Exchange 2010 Client Access server to the Exchange 2003 mailbox server.

3. If the user’s mailbox is on an Exchange 2007 Mailbox server, CAS-01 locates an Exchange 2007 Client Access server in the same Active Directory site as the user’s Mailbox server. This may be the same Active Directory site as CAS-01. CAS-01 determines whether the Exchange 2007 Client Access server has the ExternalURL property configured on the Exchange ActiveSync virtual directory. If so, CAS-01 issues the client an HTTP error code 451 that contains the ExternalURL value and instructs the client to redirect to the location specified in the ExternalURL property. If no ExternalURL value is set, the connection will be proxied to the Client Access server using the FQDN specified by the InternalURL property, specifically to the /Proxy virtual directory, This virtual directory is located beneath the Exchange ActiveSync virtual directory in IIS and, by default, has Integrated Windows authentication enabled on it.

4. If the user’s mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 provides access to the mailbox. If the user’s mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, CAS-01 locates a Client Access server in the same Active Directory site as the user’s Mailbox server. CAS-01 determines whether any Exchange 2010 Client Access server in that Active Directory site has the ExternalURL property configured on the Exchange ActiveSync virtual directory. If so, CAS-01 issues the client an HTTP error code 451 that contains the ExternalURL value and instructs the client to redirect to that location. If no ExternalURL value is set, the connection will be proxied to the Client Access server using the FQDN specified by the InternalURL property, specifically to the /Proxy virtual directory. This virtual directory is located beneath the Exchange ActiveSync virtual directory in IIS and, by default, has Integrated Windows authentication enabled on it.

Important:

Proxying isn’t possible between virtual directories that use Basic authentication. For client communications to be proxied between Exchange ActiveSync virtual directories on different servers, the /Proxy virtual directory must use Integrated Windows authentication.

Proxying and Redirection for Outlook Web App

The following series of steps shows how incoming requests are handled for a user who connects to an Exchange 2010 Client Access server named CAS-01 using Outlook Web App.

1. The Client Access server queries Active Directory to determine the location of the user’s mailbox and the version of Microsoft Exchange installed on the Mailbox server.

2. If the user’s mailbox is on an Exchange 2003 server and the user tries to access Outlook Web App using https://domain name/owa, they’ll receive an error because an Exchange 2010 Client Access server can’t directly provide Outlook Web App access to an Exchange 2003 mailbox. However, if the administrator configured redirection from Exchange 2010 to Exchange 2003, which would be usual during a migration from Exchange 2003 to Exchange 2010, the Exchange2003URL property of the Outlook Web App virtual directory was set to the value of an Exchange 2003 server facing the Internet.

3. If the user’s mailbox is on an Exchange 2007 mailbox server, CAS-01 locates a Client Access server in the same Active Directory site as the user’s mailbox server. If the Exchange 2007 Mailbox server is in the same Active Directory site as CAS-01, one of four possible actions will result.

o CAS-01 will look for an Exchange 2007 ExternalURL property that has an ExternalAuthenticationMethods setting that’s identical to the InternalAuthenticationMethods setting on the Exchange 2010 Client Access server. If the settings match, CAS-01 will redirect to this external URL. If forms-based authentication is enabled, this will result in a single sign-on redirection, which is transparent to the user.

o If a matching ExternalURL setting isn’t found, CAS-01 will look for an Exchange 2007 Client Access server that has the ExternalURL property configured, regardless of matching. If one is found, CAS-01 will redirect to this external URL. This will result in the user being prompted for authentication.

o If no matching ExternalURL setting is found, CAS-01 will look for an Exchange 2007 Client Access server with an InternalURL property that has an InternalAuthenticationMethods setting identical to the InternalAuthenticationMethods setting on the Exchange 2010 Client Access server. If one is found, CAS-01 will redirect to this InternalURL. If forms-based authentication is enabled, this will result in a single sign-on redirection.

o If no matching InternalURL is found, CAS-01 will look for an Exchange 2007 Client Access server with an InternalURL configured, regardless of matching. If one is found, CAS-01 will redirect to this InternalURL. This will result in the user being prompted for authentication.

If the Exchange 2007 Mailbox server is in a different Active Directory site, CAS-01 determines whether the ExternalURL property is set in that Active Directory site. If it is, and cross-site silent redirection hasn’t been enabled, the user is provided with a clickable link that redirects them to the specified URL. If cross-site silent redirection has been enabled, the user will be automatically redirected to the specified URL. If the ExternalURL property isn’t present, and the authentication method on the /OWA virtual directory is set to Integrated Windows authentication, CAS-01 will proxy the user’s request to the Client Access server that’s specified by the InternalURL property.

Important:

An Exchange 2010 Client Access server will never proxy Outlook Web App requests to an Exchange 2007 Client Access server in the same Active Directory site. All requests within the same Active Directory site are redirected to an Exchange 2007 Client Access server, using either the InternalURL or ExternalURL properties for Client Access server, depending on which properties are configured.

4. If the user’s mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 provides access to the mailbox. If the user’s mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, CAS-01 locates a Client Access server in the same Active Directory site as the user’s Mailbox server. When one is found, Exchange 2010 determines whether the Client Access server has the ExternalURL property set in that Active Directory site. If it is, and cross-site silent redirection hasn’t been enabled, the user is provided with a clickable link that redirects them to the specified URL. If cross-site silent redirection has been enabled, the user will be automatically redirected to the specified URL. If the ExternalURL isn’t set and the authentication method on the virtual directory is set to Integrated Windows authentication, CAS-01 will proxy the user’s request to the Client Access server that’s specified by the InternalURL property.

Proxying for the Exchange Control Panel

Exchange 2010 provides a Web-based interface for both users and organization administrators to configure settings for their mailbox or for the organization. The Exchange Control Panel (ECP) is accessed either through the Options menu in Outlook Web App or, in Outlook 2010, by choosing the Voice Mail options, requesting message tracking information, or configuring mobile notifications. Selecting any of these options within Outlook launches a Web browser session.

The destination of the session depends on the current connection state of the Outlook client. If the Outlook client is connected using RPC over TCP, the client connects to the InternalURL value of the ECP virtual directory. If the client is connected using Outlook Anywhere, the Outlook client will launch a browser session. The browser session will try to connect to the ExternalURL value of the ECP virtual directory. The URLs are provided to the Outlook client via the Autodiscover service.

When an internal client is connected through TCP, the ECP session will always connect to a Client Access server in the same Active Directory site as the user’s mailbox. Proxying isn’t used in this scenario. When a client outside the corporate network uses Outlook Anywhere to connect, the client opens a browser session to the external URL of the ECP virtual directory or to the external URL of an Internet-facing Active Directory site if the user’s mailbox is located in a non-Internet-facing site.

The proxying logic for the ECP is the same as for Outlook Web App. If the user’s mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as the Client Access server receiving the request, that Client Access server provides access to the mailbox. If the user’s mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, the Client Access server locates a Client Access server in the same Active Directory site as the user’s Mailbox server. The original Client Access server will proxy the user’s request to that Client Access server.

The ECP does perform redirection, but unless the user explicitly enters the URL to access the ECP, it’s rarely performed. If a user accesses the ECP from Outlook Web App, Outlook Web App is responsible for making sure the user is using the correct URL. If the user is using Outlook 2010, Outlook and the Autodiscover service are responsible for making sure the user uses the correct URL for the ECP.

Proxying for Exchange Web Services

Exchange Web Services provides an XML messaging interface that enables you to manage Exchange store items and access Exchange server functionality from client applications. From a proxy, redirection, and client perspective this functionality is usually used in the context of one of the following:

• Availability service requests

• Autodiscover requests

• Setting and checking Automatic Replies (OOF) status

An application written using Exchange Web Services can use proxying behavior for such tasks as setting an automatic-reply (Out of Office) message, which will be proxied between Active Directory sites, if required.

The following steps show how incoming requests are handled for a user who makes an Availability service request to an Exchange 2010 Client Access server named CAS-01. The user is using Outlook Web App to check the availability of another user in the same Exchange organization.

1. CAS-01 queries Active Directory to determine the location of the user’s mailbox and the version of Microsoft Exchange installed on the Mailbox server.

2. If the user’s mailbox is on an Exchange 2003 server, Outlook Web App makes an HTTP connection to the /Public virtual directory of the Exchange 2003 server and retrieves the requested information from the Free/Busy system folder.

3. If the user’s mailbox is on an Exchange 2007 Mailbox server, an error is returned to the user. In any Exchange organization that contains mailboxes on an Exchange 2007 Mailbox server, there must be an externally accessible Exchange 2007 Client Access server. The Autodiscover service is responsible for returning the correct Exchange Web Services URL to the client. This URL must match the version of the Mailbox server that the user’s mailbox is on.

4. If the user’s mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 accesses the mailbox itself to retrieve the requested information. If the user’s mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, CAS-01 proxies to a Client Access server in that Active Directory site by using the FQDN specified by the InternalURL property of the /EWS virtual directory.

Exchange Web Services itself doesn’t provide redirection functionality, because the Autodiscover service, which is used to provide URLs to an application, provides the URLs required to access a specific mailbox. For example, when a mailbox is moved between Active Directory sites, Outlook receives the updated Active Directory site-specific URLs from the Autodiscover service when it next issues a query. This can sometimes result in a client making Availability service requests to a Client Access server in an Active Directory site other than the one that their mailbox is in. But, because the Availability service will still process the requests and proxy them as necessary, there’s no impact on the user.

Important:

In any Exchange organization that contains mailboxes on an Exchange 2007 Mailbox server, there must be an externally accessible Exchange 2007 Client Access server. When the Autodiscover service returns the correct Exchange Web Services URL to a requesting client, this URL matches the version of server that the user’s mailbox is on. For any Exchange organization that contains mailboxes on both Exchange 2007 Mailbox servers and Exchange 2010 Mailbox servers, two external URL’s must be configured for Exchange Web Services, one for each installed version of Exchange.

Proxying for POP3 and IMAP4

Exchange 2010 can proxy POP3 and IMAP4 sessions between Client Access servers and Active Directory sites.

The following steps show how incoming requests are handled for a user who makes a request to an Exchange 2010 Client Access server named CAS-01 using a POP3 client.

1. CAS-01 queries Active Directory to determine the location of the user’s mailbox and the version of Microsoft Exchange installed on the Mailbox server.

2. If the user’s mailbox is on an Exchange 2003 server, CAS-01 proxies the connection to the POP3 service running on the Exchange 2003 server that’s hosting the user’s mailbox.

3. If the user’s mailbox is on an Exchange 2007 Mailbox server, CAS-01 locates an Exchange 2007 Client Access server in the same Active Directory site as the user’s Mailbox server, which may be in the same Active Directory site as CAS-01. CAS-01 proxies the request to the Client Access server.

4. If the user’s mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 accesses the mailbox itself. If the user’s mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, CAS-01 proxies to a Client Access server using the FQDN specified by the InternalConnectionSettings property of the POP configuration for that server.

In a Microsoft Exchange Server 2010 organization, a Client Access server can act as a proxy for other Client Access servers within the organization. This is useful when multiple Client Access servers are present in different Active Directory sites in an organization and at least one of those sites isn’t exposed to the Internet.

A Client Access server can also perform redirection for Microsoft Office Outlook Web App URLs and for Exchange ActiveSync devices. Redirection is useful when a user connects to a Client Access server that isn’t in their local Active Directory site or if a mailbox has moved between Active Directory sites. It’s also useful if the user should be using a better URL, for example, one that’s closer to the Active Directory site their mailbox resides in.

Although the Client Access server’s response can vary by protocol, when a Client Access server receives a request for a user whose mailbox is in an Active Directory site other than the one the Client Access server belongs to, it looks for the presence of an ExternalURL property on the relevant virtual directory on a Client Access server that’s in the same Active Directory site as the user’s mailbox. If the ExternalURL property exists, and the client type supports redirection (for example, Outlook Web App or Exchange ActiveSync), the Client Access server will issue a redirect to that client. If there’s no ExternalURL property present, or if the client type doesn’t support redirection (for example, POP3 or IMAP4), the Client Access server will try to proxy the connection to the target Active Directory site.

This topic explains proxying and redirection, when each is used, and how to configure your Client Access servers for each scenario.

Overview of Proxying

In Microsoft Exchange Server 2003, the front-end server communicates with the back-end server over HTTP. In Exchange Server 2007 and Exchange 2010, the Client Access server communicates with an Exchange Mailbox server over RPC. You must have an Exchange 2010 Client Access server in every Active Directory site that contains an Exchange 2010 Mailbox server. Proxying occurs when one Client Access server sends traffic to another Client Access server. An Exchange 2010 Client Access server can proxy requests in the following situations:

• Between Exchange 2010 Client Access servers Proxying requests between two Exchange 2010 Client Access servers enables organizations that have multiple Active Directory sites to designate one Client Access server as an Internet-facing server and have that server proxy requests to Client Access servers in sites that have no Internet presence. The Internet-facing Client Access server then proxies the request to the Client Access server closest to the user’s mailbox.

• Between an Exchange 2010 Client Access server and Exchange 2007 Client Access servers Proxying requests between an Exchange 2010 Client Access server and an Exchange 2007 Client Access server within one Active Directory site or between Active Directory sites enables Exchange 2010 and Exchange 2007 to coexist in the same organization.

Proxying is supported for clients that use Outlook Web App, Exchange ActiveSync, the Exchange Control Panel (ECP), POP3, IMAP4, and Exchange Web Services. Proxying is supported from one Client Access server to another Client Access server when the destination Client Access server is running the same version of Microsoft Exchange as, or an earlier version of Microsoft Exchange than, the source Client Access server.

Client Access proxying

In the previous figure, the mailbox of User 1 is located on Mailbox server 1. The mailbox of User 2 is located on Mailbox server 2, and the mailbox of User 3 is located on Mailbox server 3. Each Mailbox server is in a different Active Directory site. User 1 can access their mailbox through Client Access server 1 without using proxying, and User 2 can access their mailbox through Client Access server 2. If User 3 tries to access their mailbox through Client Access server 1 or 2, either server will proxy their request to Client Access server 3. Client Access server 3 isn’t Internet facing but can receive requests from other servers inside the firewall. Proxying isn’t visible to the user. Overview of Redirection

Overview of Redirection

Outlook Web App users who access an Internet-facing Client Access server in a different Active Directory site than the site that contains their mailbox can be redirected to the Client Access server in the same site as their Mailbox server if that Client Access server is Internet facing. When an Outlook Web App user tries to connect to a Client Access server outside the Active Directory site that contains their Mailbox server, they’ll see a Web page that contains a link to the correct Client Access server for their mailbox. This is known as manual redirection. In Exchange 2010 SP2, administrators can configure cross-site silent redirection to enable this redirection process to happen without the user’s knowledge. For more information, see Cross-Site Silent Redirection later in this topic.

Exchange ActiveSync users who access an Internet-facing Client Access server in a different Active Directory site than the site that contains their mailbox can be redirected to the Client Access server in the same site as their Mailbox server if that Client Access server is Internet facing and if the client mobile phone or device has correctly implemented the redirection logic built in to the protocol that’s used when communicating with Exchange 2007 and Exchange 2010. The redirection for Exchange ActiveSync users is achieved by sending the device an HTTP 451 error code that contains the URL the device should be using. The device then reconfigures itself to use the new URL.

The following figure shows how redirection works in an organization that has multiple Client Access servers in multiple Active Directory sites.

Redirection for Exchange ActiveSync and Outlook Web App in Exchange 2010

In the previous figure, User 1 usually accesses their mailbox in Active Directory site 1 using their mobile phone. The administrator then moves their mailbox to Mailbox server 2 in Active Directory site 2. The next time the device tries to synchronize, the server responds with an HTTP 451 status error. This contains the URL the device should now use for that user. In step 3 of the sequence, the device reconfigures itself and connects to the specified URL. User 2, whose mailbox is in Active Directory site 2, tries to open their mailbox using Outlook Web App by connecting to Client Access server 1 over the Internet. With manual redirection, as soon as the user authenticates, Client Access server 1 presents a page to the user, with a link to the Outlook Web App URL for the Client Access server in Active Directory site 2. The user clicks the link, is taken to Active Directory site 2, and signs in again to access their mailbox.With silent redirection, when the user authenticates, they’re silently redirected to the Outlook Web App URL for the Client Access server in Active Directory site 2.

Jacob Eker, PEI

 

Microsoft Lync and Microsoft Exchange 2010 UM integration

There are a lot of other resources out there that will tell you how to integrate Exchange UM with Microsoft Lync. This blog isn’t going to cover this aspect. It is covering another issue, transferring calls from an UM Auto-attendant to another extension, say a Subscriber Access number. Here is the scenario:

Client has limited amounts of DIDs, so all users use the tel:+1xxxyyyzzzz;ext=aaaa format. They have a single DID that is going to be used for an auto-attendant. They still want a Subscriber Access number, but to have it as an extension versus a DID. The extension used for the Subscriber Access number is +2999. I could not use the format above as it is 21 characters and Exchange 2010 UM has a limit of 20 characters (figures ). When you call into the AA, you press “8” or say “Subscriber Access” to be transferred. The transfers would fail to the Subscriber Access number. Transfers to users (entering extensions and/or saying their name worked every time, but transfers to Subscriber Access failed. Here’s why:

Exchange 2007 UM

First let’s cover the “old” days of OCS R2 and/or Lync integration with Exchange 2007 UM. In the past you had to have your dial-plans match exactly or the integration would fail. Example would be Lync dial-plan of “Test123.local.com”. The dial-plan you create on Exchange would need to be exactly the same “Test123.local.com” or the integration would fail. This is because when a call would come into Exchange 2007 and the call was being transferred to a user and/or another number, it would append the “Test123.local.com” to the “phone-context=” in the INVITE. Lync would see this and handle the call appropriately.

Exchange 2010 UM

With Exchange 2010 the above Exchange 2007 rules no longer apply. You no longer need the dial-plans in Lync and Exchange to match in order for the UM integration to function properly. Why? Well, Microsoft changed the way the calls are transferred. Instead of appending the “phone-context=” with the dial-plan name, it sends the calls with “phone-context=user-default@domainname.com”. This is a great change, but there is a caveat.

Caveat

The problem with the above is when the INVITE is sent using the default dial-plan, Lync matches the Global dial-plan. Some people configure the Global dial-plan, others like more personalized or easily identifiable dial-plans. So they leave the default configuration of the Global dial-plan. If you are using E.164, then this isn’t a problem as the default normalization rule prefixes a “+” to the numbers coming in. Everything and everyone is happy. In this particular installation, this wouldn’t work as the call coming in wasn’t matching the default rules and Lync was giving errors in the translation logging that it found a matching number, but it was in a different dial-plan, and the transfer would fail.

Resolution

To make the transfers work, I needed to modify the normalization rules of the Global dial-plan to match the incoming “2999” number and normalize it too “+2999”. This worked. I know I could have given a bogus E.164 (+15555552999) number instead of using a 4-digit extension, but we didn’t for other reasons.

Emilio Rivera, PEI

 

Microsoft Lync A/V Authentication Issue

In one of our most recent Lync implementations we ran into some issues of long post-dial-delay (PDD) on internal, external (Federated or Edge) and PSTN calls. The PDD was in the range of 8-10 seconds consistently. After troubleshooting, tracing packets, and pulling logs we found the issue. The issue was between the A/V Authentication service (living on the Edge server on an internal DMZ) and the Front End and Mediation servers (collocated). One of the required ports for TURN/STUN was not being allowed. All other ports were allowed, but port 443 was not specifically allowed. So – if you are experiencing long PDD delays on inbound and outbound calls, verify your firewall rules. The root cause of the issue was a typo in the access policy on the firewall. Fun experience and always a great way to remember to CHECK THE BASICS FIRST!

Emilio Rivera, PEI

Intune 2

If you don’t currently have an Microsoft Enterprise agreement, or you can’t afford a System Center Configuration Manager server, perhaps you should pick up Microsoft’s Intune product.

For a minimal monthly cost per PC, this software offers a great deal of control & reporting to your existing environment. Did I mention that this product also offers a 30 day free trial for 25 systems, and a wealth of free documentation as well.

From simple Microsoft application deployment to remote assistance, Intune offers a great central management platform for smaller companies, or a good entry level product similar to SCCM. This product offers some great core functionality in the forms of process security fixes, and other updates, alerting with things go awry, view of per PC software inventories, reporting, software deployments over the internet connections, and other admin duties.

An overview can be found here – http://www.microsoft.com/en-us/windows/windowsintune/try-and-buy.aspx#_try

Sam Westfall, PEI

TMG (Threat Management Gateway) and Windows Update Error 0x80072f8f

You’ve just installed Microsoft Forefront Threat Management Gateway (TMG) and then head off to install Windows Updates to make sure everything is up to date, when you see the nasty red X and the indecipherable error code: 0x80072f8f.

Never fear, this is simply an indication that TMG, being a firewall, is blocking the Windows Update traffic. To resolve, you just need to tell Windows to use TMG as a proxy. From an elevated command prompt, run:

netsh winhttp set proxy localhost:8080

And then run Windows Update again.

Shane Skriletz , PEI

Lync Mobility and Front-end services

This is more of a PSA entry than anything else. It was recently brought to my attention that the supported topologies for Microsoft Lync have changed slightly.

When Microsoft Lync was first released, one of the great things was that we could co-locate the Mediation service on the Front-end. This makes a lot of sense in smaller organizations who may not have a lot of PSTN calls. A lot of times, we see people dual-home the front end server so that the mediation component will utilize its own NIC. What’s wrong with that you say? Well, nothing, until…

Lync Mobility. Microsoft updated the Topologies and Components for Mobility Technet article on 12/18/2012 to reflect the following statement (Note: it is the very last statement on the page):

“The Mobility Service is not supported on dual-homed Front End Servers that are collocated with the Mediation Server role.”

http://technet.microsoft.com/en-us/library/hh690037.aspx

After asking around, it seems that this is a bug with how Lync selects the IP address for RTC and that a fix will hopefully come a future update. For now, if you want to have the Mediation service co-located on the Front-end server, you can only have a single NIC.

Adam Ball, PEI

Recommendations for Rookies – CRM Part II

I know you’re excited for the second installment of Recommendations for Rookies. Again, I will focus on Microsoft Dynamics CRM. If you missed my first article focusing on customization, you can read it here.

Q: How can I make CRM more accessible?

A: Whether you have CRM Online or CRM On-Premise there are 3 ways to make it accessible to your users. The first is through the web client. This CRM has full functionality but if you have it hosted on an internal server, users may have issues with remote access. You will have to make sure you have the proper certificates to ensure it’s available externally. CRM also has a mobile client. There are several apps out there and honestly I don’t know which one is best. I tried a few but what really worked best for me was saving the web version of CRM as a bookmark on my phone. The great thing about this approach is within the CRM customization settings you can modify the mobile view of your forms and tables. The last way is through the CRM for Outlook add-in. I’ll go into more detail later, but with the add-in, your users won’t even have to leave their e-mail to create entries and search the database.

Q: Which is better the web version of CRM or the Outlook Add-in?

A: To each their own. I prefer using web access because that is the interface I used to do all the customizations and to familiarize myself with the program. The one thing I use the Outlook client is to track e-mails, which seems obvious. The reason is, if you create an e-mail activity within the web client you must click “Send e-mail” in order to close the activity. I don’t necessarily want CRM sending those e-mails or I’m logging an incoming e-mail. One thing to look out for is the synchronization settings within Outlook. If you create a set of phone calls within the web client they will sync down to your Outlook tasks, which is fine but then if you mark a phone call as “Canceled” in CRM, Outlook thinks the call is “Complete.” Then when they sync again the value in CRM overrides to “Complete.” We like to track the number of calls our account managers are making each week and this is no bueno as it skews the data.

Q: How long will it take to bring new users up to speed?

A: Well that really depends on a couple of factors. Have they ever used a CRM program before? How technically literate are they? How is CRM configured? How many access points do they have? What is your training process? And the list goes on… As a reference point, our CRM went live about 6 months ago and our sales team, who had to transfer from our old methods of tracking, is now entering data well and consistently using the tool. Not quite perfect yet, but getting there. Our newer hires are catching on as well. I’d say the timeline ranges anywhere from 1 to 4 months to really grasp the basics of creating and updating the data, and 4+ months to learn the more advanced features, like creating personal views, dashboards, goals, workflows and queries. The best way I’ve found to speed up the process is to really familiarize yourself with the system. Click every button you can and see where everything is. Also, during our training sessions, we had users bring their laptop and practice together.

Hope my recommendations help out my fellow rookies.

Heidi Christensen, PEI