How to get save password option for Office Communicator users

Open Registry editor and locate the following key:

HKLM/Software/Policies/Microsoft/Communicator,  and set SavePassword=1.  

This enables a checkbox to save password in MOC login dialogue.

After the password is entered it is saved into the registry

HKCU/Software/Microsoft/Communicator/AccountPassword

This registry key store in hashed value. Changing the hash requires re-entering the password.

Note: You may want to use this option if MOC users login from workgroup machine, or Kerberos authentication is not working

Source :http://www.ocspedia.com/FE/How_to_Save_Password_MOC.htm

OCS 2007 R2 Server Loses network connection on Server Startup

As strange as this might sound to you but this is the latest case I have faced which in the end appeared to be a known bug and Microsoft Premiere Support were able to solve it after 3 weeks of investigation

Setup

So you have OCS 2007 R2 implemented over Windows 2008 and the Backend is placed on SQL 2008 on windows 2008 server. The below roles are all implemented on windows 2008:

• Front End 1
• Front End 2
• Mediation
• Consolidated Edge not joined to the domain

Problem:

When you restart any OCS server you cannot remote access to that server again, the Ping over the server is lost and when you go and check the server you find the network is disconnected.

If you went through all of the OCS Server services you will find them all are in the mood of starting and it will take it like 10 minutes then it will fail to start .

If you set these OCS Services to manual start rather than Automatic then reboot. You will find that the server is functioning normally.

This is really a very strange problem and I never faced it before as I have already implemented the OCS on 2008 but I still up to this moment don’t know the symptoms that causes this problem to happen.

Solution:

- Set startup type for wmiApSrv to automatic

- Add dependency on RtcSrv to wmiApSrv

- Set startup type for RtcSrv to automatic

- Reboot

- RtcSrv is starting and running

- Set startup type for all Rtc* services to automatic

- Reboot

- All Rtc* services starting and running

 

To set the RTCSrv service dependency you can use the registry to modify the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RtcSrv and modify the DependOnService to include the wmiApSrv.

The Sixth Sense Tech of the Future ( Must Watch )

Customizing Exchange UM Auto Attendant

 When you normally configure your Exchange UM auto attendant, here is the normal greeting that you will hear:

“Welcome to the Exchange Auto Attendant. Use the key pad to spell the name of the person you are calling, last name first, or to spell their e-mail alias, press the # key twice. If you know the extension, press the # key.”

One of our clients requested to change the Auto Attendant to give him in the end the below experience:

“Welcome to Company ABC, please dial the extension of person you are calling”

Which means that we need to remove the following parts from the Greeting:

·         Name lookup

·         The # key

In the end this was done by the below command from the exchange shell and of course we used a custom greeting for the first custom welcome part.

Set-UMAutoAttendant -Identity “test” –NameLookupEnabled $false

Replace “test” with the name of your Auto Attendant

Also the client asked if that greeting can be interrupted , we tested that and it appeared that it can only be interrupted after the first wav file ends which is “ welcome to the exchange auto attendant “  .

If you tried to interrupt before this greeting ends then you will hear a sorry message , however you can enter any digits and interrupt the greeting right after that 3 seconds part. 

The UC Guy is now Branded :-)

I was walking in Dubai Mall and I found a place where you can Print anything , So I though to do some Marketing for the Brand lolllll .

I Love it

OCS 2007 DNS Splitting for unique domain for Internal and External login

Here you are the Scenario that I see in all my implementation:

 

• you have organization that its internal domain name is Contoso.local
• then you install an Exchange Server whether 2003 or 2007  and you create  E-mail Policy for your public external domain which is for example @contoso.com,
• you want to implement OCS where users will log in to communicator client with a unique login address whether from internally or externally  using username@contoso.com 

OK …to accomplish this there are some tricky actions you need to do but let us first understand how things usually work so that we would better understand what exactly we need to change.

 

Certificates

·         OCS 2007 generally depends on Certificates like the air to us, so rule number one always check the certificate. Certificates are what the OCS uses to assure a secure communication between different OCS servers and also with the clients.

·         The Idea behind a certificate is simply that you create a certificate for a computer with an identity of the FQDN of the server  which is in our case here is ocsserver.contoso.local

·         Upon communication between 2 OCS Servers or between OCS servers and client , the first thing that happens is that they both exchange certificates together , the certificate assures the name of the server and must be issued from a trusted CA issuer .

DNS

·         OCS 2007 also uses the DNS SRV records whether  internally or externally to identify the OCS Server name , this is only required for the Automatic login for the OCS users , if you want to bypass this then you will manually define the OCS Server pool internally and externally for all clients using Group policy and you will just need the A records for the server name .

 

Ok now we understood the basics for the OCS, let us see what happens normally internally when communicator client trying to login, if you understood this part then you will be able to identify alone how to reconfigure this for another domain.

1.       Communicator client opens and you write an email for the login which is username@contoso.local

2.       Communicator goes to DNS to ask for the domain contoso.local and request from the DNS if there are any SRV records for this domain.

3.       If yes then the communicator retrieve the OCS server name which is serving this domain

4.       It lookup with the DNS for an A record for that OCS FQDN server

5.       When it finds it , the communicator tries to communicate with the server MTLS secure communication over 5061 port, this is secure channel where the server has to present a certificate to the client matching the FQDN which was presented by the DNS

6.       When this is confirmed then authentication completes and communicator logs in.

This way is the same whether you want to login from inside or from outside your network through edge.

Now finally let us see what we need to change here in order to make the users able to login with username@contoso.com  internally and externally

·         From the Active directory domains and trusts let us first create a new domain name prefix called contoso.com  , this will provide us with the ability to change the active directory login name from user@contoso.local to user@contoso.com   . don’t worry this will not affect the user by anyway .

·         Secondly we need to create identification for this new domain contoso.com inside our DNS servers internally and externally. So we create a new Zone inside the DNS servers with Contoso.com and make an A record for the OCS FQDN server in it OCSServer.contoso.local  and you might also need to create A record for the OCS FQDN server with the format of OCSserver.comtoso.com  . both A records will point to the same IP

·         Then the SRV record inside this zone and pointing to the OCS server

·         From the OCS Server, on the Global configuration you have to add contoso.com to the SIP domains served by the OCS.

·         Last thing now to do to make this work would be the certificate , because we need the certificates to be presented with the domain ID of contoso.com not contoso.local

 The certificate must match the FQDN returned by any DNS SRV query. Therefore, the certificate must contain multiple entries. We call these SANs (Subject Alternate Name) and the certificate must include the FQDN of the pool and one entry for each supported SIP domain.

Subject Name:  OCSSRV.contoso.local

 Subject Alternate Name:   Sip.contoso.local,sip.contoso.com,ocsserver.contoso.local,ocsserver.contoso.com

·         Now return to OCS deployment and choose configure certificate wizard,Choose to assign existing certificate and choose the new certificate you created

·         Assign the certificate in the IIS and restart IIS and OCS Front end service

·         For the external access, do the DNS part and the Certificate part again but pointing to the access edge server.

 

Now you can sign In with user@contoso.com  J  from anywhere

Appendix: How to configure a CA to accept a SAN attribute from a certificate request

By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension. If SAN entries are included in the certificate request, these entries are omitted from the issued certificate. To change this behavior, run the following commands at a command prompt on the server that runs the Certification Authority service.

Certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

OCS Integration with AVAYA ( 2 of 2 )

In the last post we talked about the Microsoft Story of the Integration using the AVAYA SES Server , now we will talk about the AVAYA story of integration which is using the AVAYA Application enablement Server ( AES )

in this scenario AVAYA uses the RCC mode or the Enterprise voice with PBX integration , thats why we need AVAYA AES Server where it will be integrating with the OCS Front end not with the Mediation. actually there will be no need for the mediation server because all the call processing will happen on the AVAYA side and the communicator client will act only as a skin or soft phone for the AVAYA PBX .

this is not the favorite scenario for microsoft as it is like the LCS with RCC which is not the Microsoft vision for moving to Microsoft IP PBX in 2010.

anyway in this scenarion you will be able to have one single extension for both AVAYA and OCS where both ends will ring , we do that by defining a static route on the oce front end server to map any communication for a client with a servers uri matching AES FQDN ” aes.mydomain.com”  to the IP of the AES Server with its static port.

on the other hand we configure the user with Server URI and Telephone URI matching the AVAYA Extension and the AVAYA AES Server. please keep in my that AES Server needs to communicate over TLS with OCS which means that certificate must be confugured right on the AES server , plus there is a trick with the Active directory user configured on the AES Server , if this is not configured right then u will get an error on the communicator client with ” NO Phone System “.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Good thing : Single extension for both AVAYA and OCS

Bad thing : 1- High cost for this feature only ( 60$ per person ) , 2- OCS conferencing is dimmed 

I am not recomending this type of integration because in the end it is just a soft phone not the OCS with its features , if this is what you are looking for  then use AVAYA softphone  and the OCS wont be needed.