Microsoft Ignite 2015 – Office 365 Development Session : Get Your Hands Dirty with the Office 365 RESTful APIs

https://channel9.msdn.com/Events/Ignite/2015/BRK4117/player

I love this great session presented by Rob Howard; this session dives into the available scenarios when using the OneDrive for Business, Calendar, Mail, Contacts and Sites services in the Office 365 APIs. These Office 365 APIs can be called by any standalone web app or mobile device app. There are built in Visual Studio wizards, in the majority of Project Templates, to connect to them, handling all of the authentication flow and class libraries that help to call them. Understand the Azure Active Directory authentication flow. Understand scenarios available across Calendar, Mail and Contacts. Learn how to get started and work with the Calendar, Mail and Contacts. See how to implement these services in real-world scenarios in your own web apps.

Happy O365 development!!

PowerShell: Determine Version number, build number and Service Pack of Exchange Server

In my earlier article, we learnt how to get the Exchange Server version, version/build number of Exchange 2003 and it’s earlier. In this, we will see how to get these info & couple of additional info in Exchange Server 2007/2010 using Exchange Management Shell and Exchange Management Console.

Using Exchange Management Console:

To view the server properties in the Exchange Management console, try the following steps:

1.Start the Microsoft Exchange Management console. In the navigation pane, expand the Server Configuration objects until you locate the server object, and then select the server object.
2.On the right side, notice the Exchange version number.

Using Exchange Management Shell:

For this, I used Get-ExchangeServer cmdlet to view the server properties in Exchange Management Shell:

I want to save the above info in a .txt file (saved under c:output.txt):

Now, I want to customize the above one by the following to get more clarity:

Still I want to add more info like Site, Server Role and Edition etc..

Hope this helps you to move ahead.

Migration: 500,000 Windows Live Spaces blogs migrated to WordPress.com

Recently we heard the announcement regarding Microsoft Windows Live Spaces blogs working with WordPress.com to let customers connect the fantastic blogging capabilities of WordPress with the leading communications and sharing services of Windows Live.

Per Dharmesh Mehta, Director of Windows Live Product Management, as of today, just over half a million Spaces blogs have now migrated to WordPress.com. On top of that, nearly half a million additional Windows Live customers have decided to create entirely new blogs on WordPress.com.  And for each of those nearly 1 million new people now blogging on WordPress.com, there are, of course, many more new blog visitors also now going to WordPress.com. 

People are continuing to migrate their Spaces blogs over to WordPress.com, and to those of you who haven’t gotten around to it yet, we want to remind you that you’ll need to do so before March 2011.

As part of this partnership, we’re helping customers to migrate their existing Windows Live Spaces blogs over to WordPress.com. Also we’re using the power of Messenger Connect to help customers share their blog posts with their Messenger friends.

I too migrated my Windows Live site to WordPress.com

Receive Server Error while browsing the Exchange EWS or Autodiscover sites

Recently i received the following error while try to browse the following /autodiscover/Autodiscover.xml">https://<servername>/autodiscover/Autodiscover.xml  or /ews/exchange.asmx">https://<servername>/ews/exchange.asmx:

Could not load file or assembly ‘Microsoft.Exchange.Diagnostics, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Exchange.Diagnostics, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Assembly Load Trace: The following information can be helpful to determine why the assembly ‘Microsoft.Exchange.Diagnostics, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ could not be loaded.

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLMSoftwareMicrosoftFusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLMSoftwareMicrosoftFusion!EnableLog].

Stack Trace:

[FileNotFoundException: Could not load file or assembly ‘Microsoft.Exchange.Diagnostics, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.]
Microsoft.Exchange.Services.AuthorizationModule.Init(HttpApplication context) +0
System.Web.HttpApplication.InitModulesCommon() +135
System.Web.HttpApplication.InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers) +2601588
System.Web.HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context) +347
System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context) +139
System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +196

——————————————————————————–
Version Information: Microsoft .NET Framework Version:2.0.50727.1434; ASP.NET Version:2.0.50727.1434

During the analysis, i noticed that the issue had happened as it could not load the assembly Microsoft.Exchange.Diagnostics due to incorrect entry in the application web.config file. I followed the below steps to over come the issue specified in the KB.

If the problem is occurring with /autodiscover/autodiscover.xml">https://<servername>/autodiscover/autodiscover.xml

Take a backup of web.config in "C:Program FilesMicrosoftExchange ServerClientAccessAutodiscover".
– Open web.config from C:Program FilesMicrosoftExchange ServerClientAccessAutodiscover in notepad.
– Replace all "file:///%ExchangeInstallDir%" with "file:///C:Program FilesMicrosoftExchange Server" where C is the drive where Exchange is installed.
– Save the file.
– Open an Administrator command prompt and run IISreset /noforce
– Test browsing /autodiscover/autodiscover.xml">https://<servername>/autodiscover/autodiscover.xml

If the problem is occurring with /ews/exchange.asmx">https://<servername>/ews/exchange.asmx 

Take a backup of web.config in "C:Program FilesMicrosoftExchange ServerClientAccessexchwebews".
– Open web.config from C:Program FilesMicrosoftExchange ServerClientAccessexchwebews in notepad.
– Replace all "file:///%ExchangeInstallDir%" with "file:///C:Program FilesMicrosoftExchange Server" where C is the drive where Exchange is installed.
– Save the file.
– Open an Administrator command prompt and run IISreset /noforce
– Test browsing /ews/exchange.asmx">https://<servername>/ews/exchange.asmx

Hope this helps.

Security warning: The name of the security certificate is invalid or does not match the name of the site

Recently i started MS Outlook 2007 and tried connecting to a mailbox that is hosted on a mailbox server that is running Microsoft Exchange Server 2010 inside the local network. I received the following security warning “The name of the security certificate is invalid or does not match the name of the site.”

During my analysis, i found that this error had happened due to the default self-signed Exchange Server 2010 certificate – it causing a name mismatch error to occur.

Also regarding this, i found the following support knowledgebase article talks about it – this scenario applies only to Outlook clients that connect to Exchange from inside the local network.In order to overcome the problem and the article provides resolution also.

Based on the above article this issue may occur if the following conditions are true:

• You replace the default self-signed Exchange Server 2007 or Exchange Server 2010 certificate with a different certificate.
  Note The Setup program in Exchange Server 2007 or in Exchange Server 2010 creates a default self-signed certificate when Exchange Server 2007 or Exchange Server 2010 is installed.
• The common name on the replacement certificate does not match the fully qualified domain name (FQDN) of the URL that is stored in the following objects:
  • The Service Connection Point object for the Auto discover service
  • The InternalUrl attribute of Exchange 2007 Web Service (EWS)
  • The InternalUrl attribute of the Offline Address Book Web service
  • The InternalUrl attribute of the Exchange unified messaging (UM) Web service

By default, the URL that is stored in these objects references the NetBIOS name of the server. For example, a URL that resembles the following URL is stored:

https://NetBIOS_name.contoso.com/autodiscover/autodiscover.xml

This may differ from the host name that is used in the FQDN of the replacement certificate. For example, the replacement certificate may have an FQDN that resembles the following FQDN: mail.contoso.com

This issue causes a name mismatch error to occur. Therefore, you receive the security warning message when you try to connect Outlook 2007 to the mailbox

Why Windows Vista based client prompts to enter your credentials when you access an FQDN site?

One of my customer reported that whenever he tries to use Web Distributed Authoring and Versioning (WebDav) to access a fully qualified domain names (FQDN) site. But he is prompted to enter the credentials, even though the user account that we are using has sufficient permission to access this site. During the research we found that he tries to access from a Windows Vista-based computer, where he do not configure a proxy in Windows Internet Explorer and he gets this issue/prompt.

It’s because, in Windows Vista, Internet Explorer uses the Web Client service when you use Internet Explorer to access a WebDAV resource. The Web Client Service uses Windows HTTP Services (WinHTTP) to perform the network I/O to the remote host. WinHTTP sends user credentials only in response to requests that occur on a local intranet site. However, WinHTTP does not check the security zone settings in Internet Explorer to determine whether a Web site is in a zone that lets credentials be sent automatically.

If no proxy is configured, WinHTTP sends credentials only to local intranet sites.

Note If the URL contains no period in the server’s name, such as in the following example, the server is assumed to be on a local intranet site: http://sharepoint/davshare

If the URL contains periods, the server is assumed to be on the Internet. The periods indicate that you use an FQDN address. Therefore, no credentials are automatically sent to this server unless a proxy is configured and unless this server is indicated for proxy bypass.

Note A server can be indicated for proxy bypass either through the bypass list or through the proxy configuration script.

In this case, you are prompted to enter your credentials when the Web site asks for credentials. Even in this case, the security zone settings are ignored.

Hotfix available: To overcome this issue, a supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hot fix only to systems that are experiencing this specific problem.

Important This hotfix is included in Windows Vista Service Pack 1 or a later service pack. However, you must still configure the AuthForwardServerList registry entry. For more information, see the Registry information section.