Click below to read about the new Internet Explorer 9 Web Browser from Microsoft. Looks nice at first glance, getting more and more integrated like Windows Explorer and some nice features such as pinned websites too!
http://blogs.technet.com/b/uktechnet/archive/2010/09/15/internet-explorer-9-beta-for-it-professionals-ie9-a-guest-post-by-simon-may.aspx
Kevin Greene's IT Blog. This is a blog about all things Cloud and Datacenter!
Thursday, September 16, 2010
Tuesday, September 14, 2010
Enabling UAG 2010 UPN Logon
Another UAG 2010 issue that we came across!!
By default, true UPN logon (e.g. username@domain.com) is not enabled when logging onto a UAG trunk. As a result, we had a site with UAG 2010 enabled and an SSL Portal presenting OWA and Sharepoint out to the internet. We had SSO configured for AD authentication.
When we would logon to the SSL Portal with a standard username such as kevin.greene, then OWA and Sharepoint would work fine. When we attempted to logon to the portal with a UPN such as kevin.greene@domain.com, then the OWA application would work fine, but the Sharepoint app would present us with a 'Permission Not Granted' error message and would proceed no further. When we monitored the UAG Web Monitor, we found that UAG was processing the UPN logon as domain\kevin.greene@domain.com and when Sharepoint attempted to read this logon string, it didn't want to know about it!!!
We found this on Microsoft's Technet site that pointed us in the right direction to resolving the UPN logon issue:
http://technet.microsoft.com/en-us/library/ee809087.aspx
If you take a look at the section that describes the 'TranslateUPN' registry key, there are 5 steps to follow that will enable UPN logon to pass through correctly to the Sharepoint server.
Hope this saves someone else out there some time on site!!
By default, true UPN logon (e.g. username@domain.com) is not enabled when logging onto a UAG trunk. As a result, we had a site with UAG 2010 enabled and an SSL Portal presenting OWA and Sharepoint out to the internet. We had SSO configured for AD authentication.
When we would logon to the SSL Portal with a standard username such as kevin.greene, then OWA and Sharepoint would work fine. When we attempted to logon to the portal with a UPN such as kevin.greene@domain.com, then the OWA application would work fine, but the Sharepoint app would present us with a 'Permission Not Granted' error message and would proceed no further. When we monitored the UAG Web Monitor, we found that UAG was processing the UPN logon as domain\kevin.greene@domain.com and when Sharepoint attempted to read this logon string, it didn't want to know about it!!!
We found this on Microsoft's Technet site that pointed us in the right direction to resolving the UPN logon issue:
http://technet.microsoft.com/en-us/library/ee809087.aspx
If you take a look at the section that describes the 'TranslateUPN' registry key, there are 5 steps to follow that will enable UPN logon to pass through correctly to the Sharepoint server.
Hope this saves someone else out there some time on site!!
Publishing Sharepoint 2007 with UAG 2010 SSL Portal
We have been working on a site which requires a bespoke configuration to present their internal applications such as OWA, Sharepoint,CRM and some legacy out onto the Internet.
The solution that we have recommended to securely publish these resources and integrate them into Active Directory authentication is to install TMG 2010 alongside UAG 2010 within a Microsoft Hyper V 2008 R2 cluster environment.
We had suggested to the customer that they could present the resources either through a single url SSL Portal - e.g. https://vpn.domainname.com/ or through individual application trunks such as - https://owa.domainname.com/ or https://sharepoint.domainname.com/
When we went about deploying the remote access, the OWA publishing worked straight away both inside the UAG SSL Portal and also as an individual trunk through https://webmail.domainname.com/
The problems all started when we tried to get the published Sharepoint resources out through UAG. Firstly, this customer had a contiguous namespace for their DNS as per the recommended configuration by Microsoft, e.g. internal was domainname.com and external was domainname.com. Secondly, they were accessing their internal Sharepoint server over port 80 (HTTP) and naturally wanted to access their external Sharepoint resource through port 443 (SSL).
When the Sharepoint was presented through the SSL Portal configuration, we would have all of the applications contained within one single window after the original Single Sign On (SSO)of Active Directory was authenticated. The url at the top of this Portal was https://vpn.domainname.com/
When we clicked on the Sharepoint application to open the site, the site would open in an new page, but would have a url of https://vpn.domainname.com/
Although most of the links worked, when documents were tested to be checked in or out, created or deleted, we came across a number of errors and quickly realised that we needed to translate the original url of the internal Sharepoint site across to the UAG SSL Portal application - https://sharepoint.domainname.com/ instead of the Portal url of https://vpn.domainname.com/
This is where the fun began! Mainly because of our lack of experience on the installation of this product, and also because of the lack of concise documentation on UAG, we had all kinds of issues trying to get this to work.
Eventually, we called in our resources from Microsoft Ireland who put me in touch with a UAG Specialist in the UK. Here is the basics of what we had to do in order to get the URL Translation working between Sharepoint and UAG 2010:
1.Changed the Web Servers Tab and Portal link tab so that https://sharepoint.domainname.com was used as the public host name for SharePoint
2.Changed the Path on the Web Servers tab to ‘/’
3.Used a ‘fake’ host header to allow SharePoint to distinguish between intranet and internet clients
4.Configured SharePoint AAM rules to generate the correct public URLs for Internet clients
It's worth noting that these steps were additonally on top of the original configuration that we had implemented and they were the changes needed to get the configuration working the way we needed.
After all that, I'm now at last much clearer on configuring UAG 2010 with Sharepoint thankfully!
The solution that we have recommended to securely publish these resources and integrate them into Active Directory authentication is to install TMG 2010 alongside UAG 2010 within a Microsoft Hyper V 2008 R2 cluster environment.
We had suggested to the customer that they could present the resources either through a single url SSL Portal - e.g. https://vpn.domainname.com/ or through individual application trunks such as - https://owa.domainname.com/ or https://sharepoint.domainname.com/
When we went about deploying the remote access, the OWA publishing worked straight away both inside the UAG SSL Portal and also as an individual trunk through https://webmail.domainname.com/
The problems all started when we tried to get the published Sharepoint resources out through UAG. Firstly, this customer had a contiguous namespace for their DNS as per the recommended configuration by Microsoft, e.g. internal was domainname.com and external was domainname.com. Secondly, they were accessing their internal Sharepoint server over port 80 (HTTP) and naturally wanted to access their external Sharepoint resource through port 443 (SSL).
When the Sharepoint was presented through the SSL Portal configuration, we would have all of the applications contained within one single window after the original Single Sign On (SSO)of Active Directory was authenticated. The url at the top of this Portal was https://vpn.domainname.com/
When we clicked on the Sharepoint application to open the site, the site would open in an new page, but would have a url of https://vpn.domainname.com/
Although most of the links worked, when documents were tested to be checked in or out, created or deleted, we came across a number of errors and quickly realised that we needed to translate the original url of the internal Sharepoint site across to the UAG SSL Portal application - https://sharepoint.domainname.com/ instead of the Portal url of https://vpn.domainname.com/
This is where the fun began! Mainly because of our lack of experience on the installation of this product, and also because of the lack of concise documentation on UAG, we had all kinds of issues trying to get this to work.
Eventually, we called in our resources from Microsoft Ireland who put me in touch with a UAG Specialist in the UK. Here is the basics of what we had to do in order to get the URL Translation working between Sharepoint and UAG 2010:
1.Changed the Web Servers Tab and Portal link tab so that https://sharepoint.domainname.com was used as the public host name for SharePoint
2.Changed the Path on the Web Servers tab to ‘/’
3.Used a ‘fake’ host header to allow SharePoint to distinguish between intranet and internet clients
4.Configured SharePoint AAM rules to generate the correct public URLs for Internet clients
It's worth noting that these steps were additonally on top of the original configuration that we had implemented and they were the changes needed to get the configuration working the way we needed.
After all that, I'm now at last much clearer on configuring UAG 2010 with Sharepoint thankfully!
Creating Graphical Reports in Exchange 2007
For those of you that ever wanted to utilise the raw data contained within the Exchange Server message logs, then here is an excerpt from an excellent article from msexchange.org explaining how to deploy a reporting solution using free Microsoft tools to create nice bar charts, data tables and even 3D pie charts!
We had a customer that had a particular need to present a report to internal management that contained the top 50 senders and receivers of email. Now this might sound like a simple enough report to generate from any anti spam or email monitoring device, but as we found out, the reports these devices can churn out, are mainly based around top spam users or top blocked users. This customer wanted a report that detailed everything - spam included!
This solution will work on Exchange 2003, Exchange 2007 and also Exchange 2010 (DAG configuration not supported though).
This solution utilises the Microsoft Log Parser tool version 2.2 to query the log files and generate the reports that you need.
Once the Log Parser is installed and the additional Microsoft Office Addins (pre-requisites too), then it is all about old fashioned command line scripting (no advanced training needed though) to get the reports that you need.
We had to stray slightly from the steps within the document I've linked to but with a little perseverence, we managed to generate some pretty cool reports that the customer was delighted with considering it cost nothing to implement!
Here's the link to the full document on msexchange.org's website:
Part 1
http://www.msexchange.org/articles_tutorials/exchange-server-2007/monitoring-operations/creating-graphical-reports-exchange-2007-part1.html
Part 2
http://www.msexchange.org/articles_tutorials/exchange-server-2007/monitoring-operations/creating-graphical-reports-exchange-2007-part2.html
Part 3
http://www.msexchange.org/articles_tutorials/exchange-server-2007/monitoring-operations/creating-graphical-reports-exchange-2007-part3.html
Happy scripting!
We had a customer that had a particular need to present a report to internal management that contained the top 50 senders and receivers of email. Now this might sound like a simple enough report to generate from any anti spam or email monitoring device, but as we found out, the reports these devices can churn out, are mainly based around top spam users or top blocked users. This customer wanted a report that detailed everything - spam included!
This solution will work on Exchange 2003, Exchange 2007 and also Exchange 2010 (DAG configuration not supported though).
This solution utilises the Microsoft Log Parser tool version 2.2 to query the log files and generate the reports that you need.
Once the Log Parser is installed and the additional Microsoft Office Addins (pre-requisites too), then it is all about old fashioned command line scripting (no advanced training needed though) to get the reports that you need.
We had to stray slightly from the steps within the document I've linked to but with a little perseverence, we managed to generate some pretty cool reports that the customer was delighted with considering it cost nothing to implement!
Here's the link to the full document on msexchange.org's website:
Part 1
http://www.msexchange.org/articles_tutorials/exchange-server-2007/monitoring-operations/creating-graphical-reports-exchange-2007-part1.html
Part 2
http://www.msexchange.org/articles_tutorials/exchange-server-2007/monitoring-operations/creating-graphical-reports-exchange-2007-part2.html
Part 3
http://www.msexchange.org/articles_tutorials/exchange-server-2007/monitoring-operations/creating-graphical-reports-exchange-2007-part3.html
Happy scripting!
Subscribe to:
Posts (Atom)