Zoho Banner September 2011

The first thing that struck me after lifting the phone out of the box was how heavy it was. My Samsung S3 (the sole victim of a fatal hit-and-run incident recently) was much lighter.

It feels substantial, solid and it definitely won’t bend in your pocket! I wouldn’t want to drop it though. The brushed metal edging makes it look classy, but at the same time a tad rigid, and I can’t help thinking some of cheaper models with plastic surrounds might survive a fall better. I’ve been looking around for a good case – something that won’t spoil the phone’s good looks or make it look like an encyclopaedia in my pocket.

20141112_065450_resized 20141112_065538_resized 20141112_065508_resized

After three weeks the phone and I are getting on really well. I was more than slightly prepared to hate it after having had Android phones for the past 5 years. I don’t miss my S3 and have few things to quibble about. Here’s a quick summary of the pros and cons as I see them…

Pros

  • The screen clarity is amazing. Text and graphics are razor sharp and orange-effect theme is attractive to the eye.
  • The camera is mind-blowing. I can’t believe a phone can have a 20MP camera built-in!  I’m possibly the world’s worst photographer, but I’ve even managed to take some attractive looking pics (check out the photo of Breaker Bay, Wellington below).

WP_20141031_19_01_49_Pro

  • The processor has plenty of grunt. Apps load quickly and you don’t seem to spend time waiting for things to load. The exception is if the app is waiting for content to be downloaded from the web or for location information to sync.
  • Windows tiles, metro (or whatever you want to call it) work really very well on the phone. I’ve pretty much got everything I need accessible from the 3 tile columns above the page fold.
  • In-call sound quality is excellent. This wasn’t always the case with my S3.
  • The built-in speaker is awesome. I like to listen to web-radio or podcasts if I can’t sleep at night. The sound quality from the tiny speaker is really very good – rounded and not at tinny like you might expect.

Cons

  • I miss the notification lights on the S3. It was helpful to simply glance at the phone occasionally to see if I’d missed a call or a SMS. Not so with the 930 where I have to unlock the screen to look at my notifications.
  • No Cortana in New Zealand. I’m not sure how much I’d actually use Cortana, but I’d like to have the option of using it to find out where to find a decent Islay single malt locally for under $75. I’m slightly peeved one of the most touted features of Windows Phone 8.1 isn’t available to me. And, yes, I know there are ways to get Cortana to work by setting everything to US/English, but this breaks other things (such as BBC iPlayer).
  • The touch screen is not quite as responsive as the S3. I find I have to tap the screen a little harder.  Not a biggie - I’m getting used to it.

A lot of people bang on about the paucity of Apps available for Windows Phone. I use only about half a dozen well-known Apps and they’re all available from the store, so it’s not been an issue for me.

All-in-all I’m a happy camper. Even more satisfying is that I didn’t pay a fortune for it. It cost me NZD640 with shipping (via a parallel importer). That’s around about the same as a Samsung Galaxy S5 and about NZD350 cheaper than an iPhone 6.

 

A question came up in the forums today about how to use the AD Powershell cmdlets to find objects with attribute values that contain a single space. It’s a good question and relevant because often your results can be skewed by such values when searching for attributes that are not NULL (a space character is not a NULL). Anyway, here’s an example of how to do it using the LDAPFilter.

Get-ADUser -LDAPFilter "(telephonenumber=\20)"

The “\” is the standard escape character for use in LDAP searches and “20″ is the HEX representation of the space character.

The filter should also work with other LDAP clients (e.g. LDP.EXE).

 

You might come across a slight gotcha with SPF records if are using Exchange Online Protection (EOP) to provide protection for your on-premises mail environment and you don’t need to use EOP to scan your outbound (i.e. on-premises to Internet) messages. If this scenario is of interest to you, read on…

You may be aware that I run a mailing list running on a single server over at ActiveDir.org that provides a forum for disucssions on the topic of Active Directory. I set up Exchange Online Protection (EOP) to cover the mail.activedir.org namespace a little while ago as a lower-cost alternative to my previous anti-malware provider. When you first set up EOP with there are some DNS records that you are asked to configure. In fact, these *appear* to be mandatory based on the wording (see below).

EOP1

Without really thinking too deeply about I went ahead and configured the TXT record in DNS for SPF. With hindsight I shouldn’t have done this as I only wanted the traffic from the Internet to my on-premises mail server to be scanned for malware. I don’t need the SMTP traffic in the other direction to be scanned for malware because the only mail generated on the server is from the mailing list (list server) and as such as been scanned on the way in.

All appeared fine for a month or so and then fellow MVP Brian Arkills queried why he wasn’t receiving any email from the list. After a bit of digging, his infrastructure guy pointed to a problem with my SPF TXT record. Basically, the “-all” part of the record indicates that only the servers matching spf.protection.outlook.com are responsible for sending mail from mail.activedir.org. If a different server tries to deliver mail from that address the receiving MTA should fail the SPF check. Interestingly, most organisations treat this as a soft fail and deliver the email anyway. Not so the University of Washington, which is why Brian wasn’t receiving the list emails.

Once alerted to the problem, I modified the record like this:

v=spf1 a -all

What this says to the receiving MTA is to only pass the SPF check if sending server matches the A record for the namespace (i.e. my mail server).

That all seemed fine but then I looked at the message headers for emails that I was receiving from the list.  I am subscribed to the list with a standard cloud-based O365 email address. The header contained the following:

Received-SPF: Fail (protection.outlook.com: domain of mail.activedir.org does not designate 157.55.234.61 as permitted sender)  receiver=protection.outlook.com; client-ip=157.55.234.61;  helo=emea01-db3-obe.outbound.protection.outlook.com; Authentication-Results: spf=fail (sender IP is 157.55.234.61)  smtp.mailfrom=activedir-owner@mail.activedir.org;

The 157.55.234.61 IP address maps to emea01-db3-obe.outbound.protection.outlook.com (very clearly not my mail server). So what was going on? Why was the sending server showing as one of the outlook.com servers and not my mail server? I don’t know for sure but my best guess is that the O365 cloud servers are also EOP servers (makes sense). The EOP servers *think* they are responsible for the mail.activedir.org namespace and as such will effectively take over as the perceived sending server. The upshot was that I needed to go back to my SPF record and change it to include the EOP servers. It now looks like this:

v=spf1 a include:spf.protection.outlook.com -all

To summarise then:

  • Emails coming from my mail server to non-O365 addresses need to have a SPF TXT record that matches my mail server (via the A record for mail.activedir.org).
  • Emails coming from my mail server to O365 addresses need to have a SPF TXT record that matches the name required by EOP (spf.protection.outlook.com)

More than slightly confusing isn’t it? But then I guess I have a slightly unusual configuration.

For more information on SPF, this web site is a great starting point: http://www.openspf.org/

It’s sometimes interesting to know how old your AD forest is and when the various domains were created.  I recently came across a really useful TechNet Blog with a Powershell snippet to do just this.  My version shown below just has some slightly different formatting.

# How old is the forest?
Get-ADObject -SearchBase (Get-ADForest).PartitionsContainer `
-LDAPFilter "(&(objectClass=crossRef)(systemFlags=3))" `
-pr dnsRoot, nETBIOSName, whenCreated | Sort whenCreated `
| select @{e={($_.DNSRoot)};l=”DomainFQDN”}, `
nETBIOSName, @{e={(get-date $_.whencreated -format dd/MM/yyyy)};l=”whenCreated”} `
| ft -AutoSize

The output should look something like this:

check-forestage

So how old is your forest?

To be honest I’m only writing this one because I know I’ll get confused in the future and will want to refer to something authoritative. :-)

There are two configurable values when considering how to change the Exchange Server 2013 Offline Address Book (OAB) generation schedule from its default of 1 day.  These are:

  • OABGeneratorWorkCycle
  • OABGeneratorWorkCycleCheckpoint

Both are set to 1 day by default.

The values are not well documented and there are conflicting sources on the Internet that describe how they should be set to modify the generation schedule.  From testing, the key value is the OABGeneratorWorkCycleCheckpoint.  If you set this down to, e.g. 2 hours, the OAB will be generated every two hours as the screenshot below clearly shows:

OAB_WorkCycle

The command to set the value on all mailbox servers is shown below:

Get-MailboxServer | Set-MailboxServer -OABGeneratorWorkCycle 01:00:00 -OABGeneratorWorkCycleCheckpoint 02:00:00

Hopefully, this clears up the confusion for you as well as me :-)

If you have Send As permissions on another recipient object (e.g. mailbox, distribution group) you have the ability to specify that object’s primary SMTP address as your “From” address when sending from Outlook and Outlook Web App (OWA).  How you achieve this in OWA is not immediately obvious, so here are some (hopefully helpful) screenshots.  The method works for both Exchange 2013 on-premises and Office 365 OWA.

1. In the New Mail pane, click on the three dots to expose additional options.  Select “Show From”.

002

 

2. With the From field visible, right-click the email address shown and select “Remove”.

003

3. Click on the drop-down arrow in the From field.  From there select the address you which to send from/send as.

004

4. The address should now appear in the From field.  When you send the email it will send from the address shown.

005

That’s all there is to it.  It’s not rocket science, but then it’s not blindingly obvious either.

 

Let me start out by saying that I am not an Apple-hater. Nor do I have an irrational fear of their products [incredibly, there is a word for a fear of apples: Malusdomesticaphobia]. Generally, I find Apple’s products to be stylish and simple to use. So why would I find myself suffused with a feeling of schadenfreude upon learning of the bend problem (hashtag #bendgate) with the iPhone 6 Plus?  After some soul-searching I came to conclusion that my problem has less to do with Apple than the those who slavishly support the company and everything it churns out. In terms of blind faith and unswerving devotion, most religious cults would gladly trade disciples with Apple.

However this unquestioning devotion has come to pass it is clearly good for business. As a work colleague suggested, Apple could produce a plain cardboard cube and, following the requisite glitzy launch, fans would be camping out all night outside iStores ready to snap them up at $100 a pop.

The zealotry doesn’t stop there as is evidenced in recent Apple-related forums discussing bendgate. If anyone has the temerity to suggest that the bend is a fundamental product flaw they are quickly slapped down.  Here are some examples:

 

001

 

002

 

 

 

003

 

004

 

005

 

 

006

 

007

 

 

008

 

It is interesting and revealing that after the social media storm yesterday surrounding bendgate Apple has yet to comment.  I suspect the execs are too busy roasting the Test Manager’s testicles over an open flame. To a certain extent they don’t actually need to comment. After all, their Apple fan-base is doing a sterling job of defending the indefensible.

The bottom line is that Apple has released a premium product with a fundamental flaw. The right thing to do of course would be to start by issuing an immediate statement indicating that they fully understand the concerns. Then within a couple of days they should issue a statement being clear about how they will address the flaw. If, on the other hand, they attempt to sweep the whole business under the carpet they won’t lose the die-hard fans, but they will certainly lose the middle ground. That way madness (or at least Blackberry) lies.

Samsung, LG, Microsoft and others will be lapping this up, while at the same time furiously flogging their product development and test teams to ensure the same thing doesn’t happen to them.

Bendgate is a story with legs. I can’t wait for the next instalment.

If you haven’t heard that extended support for Windows XP ended earlier this year you’ve clearly been in a coma.  There are a number of well-publicised methods for finding out whether you still have XP machines in your environment.  Here is my own humble (and spectacularly over engineered) Powershell offering.

 

#########################################################
#
# Name: Find-XPStillActive.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 23/09/2014
# Comment: PowerShell 2.0 script to find active
# Windows XP computer accounts
#
#########################################################

## Define global variables
# Export file for storing results
$expfile = "c:\xp_still_active.csv"
# Define the header row for the CSV (we will create our own)
$header = "`"name`",`"os`",`"sp`",`"lastlogondate`""
# Consider any account logged on in the last x days to be active
$days = 60
$Today = Get-date
$SubtractDays = New-Object System.TimeSpan $days, 0, 0, 0, 0
$StartDate = $Today.Subtract($SubtractDays)
$startdate = $startdate.ToFiletime()
# LDAP filter settings
$filter = "(&(lastlogontimestamp>=$startDate)(operatingsystem=Windows XP*))"

## Functions
Function Format-ShortDate ($fdate)
{
        if ($fdate) {
            $day = $fdate.day
            $month = $fdate.month
            $year = $fdate.year
            "$day/$month/$year"
        } # end if

} # end function

## Start doing things
# Import the AD module
ipmo ActiveDirectory
# Tidy up any previous copies of the export file 
if (test-path $expfile) {Remove-Item $expfile}
# Add the header row to the export file
Add-Content -Value $header -Path $expfile
# Create an array of computer objects
$active = Get-ADComputer -LDAPFilter $filter -pr *
# loop through the array
foreach ($xp in $active) {
    # Grab the attribute values we need from the AD object
    $nm = $xp.name
    $os = $xp.operatingsystem
    $sp = $xp.operatingsystemservicepack
    $lt = Format-ShortDate $($xp.lastlogondate)
    $row = "`"$nm`",`"$os`",`"$sp`",`"$lt`""
    # Commit the row to the export file
    Add-Content -Value $row -Path $expfile
} # end foreach

## End script

Enjoy!

 

There was in interesting discussion the other day on the ActiveDir.org mailing list. Someone asked how many values can be stored within the proxyAddresses mutlivalued attribute in Active Directory. The responses were reasonably consistent, with most people indicating that in Windows 2000 the number was in the range of approximately 800 to 850 and from Windows 2000 the range is approximately 1200 to 1300.

This begs the question of why we can’t be specific about the number. Well, it comes down to how the data is stored within the Active Directory database (ntds.dit). Most of the attribute data for an individual object is stored within a single row in the Data Table within the database. I say “most” because linked attribute data (e.g. member/memberof, manager/directReports, etc.) is kept in a separate table (the Link Table). The AD schema determines how many attributes are available for a particular object and this obviously varies a lot from forest to forest, as does which of those possible attributes actually have populated values. There are also some overhead requirements that vary. All this combines to make it impossible to determine with any accuracy how many values an individual multivalued, nonlinked attribute can have.

Because I have an enquiring mind (some would say “nosey bastard”), I decided to try and hit the limit in my test lab. I did this by running a Powershell script to keep adding SMTP addresses to the proxyAddresses attribute for a user until an exception was thrown. I got to 1192 before I got the “The administrative limit for this request was exceeded” error (see below).

admin_limit

As Don Hacherl (former dev lead for AD at Microsoft) pointed out to me on the mailing list, the non-linked attribute limit is a limit across all non-linked attributes on the object. So for example, if I had added a telephone number before running the script then I would have only got to 1191 values on proxyAddresses.

Don also made is clear that under normal circumstances you shouldn’t need to be anywhere near the limit. In his words…

“The limit is supposed to be high enough that the only time you’ll hit it is when you have made an architectural error in your schema usage. Asking questions about the exact number of a limit that you have not yet hit is often a warning sign of your burning desire to make an architectural error in the future.”

I found a Powershell script on Experts Exchange that seemed to be useful for detecting errant objects that have a high number of values within an individual multivalued attribute. I’ve hacked with it a bit and have ensured that it now excludes linked values. Here it is for anyone that is interested.

#########################################################
#
# Name: Find-BloatedObjects.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 18/09/2014
# Comment: PowerShell 2.0 script to
# find objects with an unusually large number of values
# within a non-linked multi-valued attribute
# Credit: Parts of the script are from a solution posted by 
# footech on Experts Exchange here:
# http://tinyurl.com/md3cvzn
#
#########################################################

Import-Module ActiveDirectory
$queryCount = 1000 # adjust this if you need to
$snc = (Get-ADRootDSE).SchemaNamingContext
$dnc = (Get-ADRootDSE).DefaultNamingContext
$def = "Microsoft.ActiveDirectory.Management.ADPropertyValueCollection*"
$objs = Get-ADObject -Filter * -Properties * -SearchBase $dnc

ForEach ($obj in $objs) {
    #Write-Output "Looking at object $obj.distinguishedname"
    $ADOprops = $obj | gm -MemberType Property `
    | Where { $_.Definition -like $def } `
    | Select -ExpandProperty Name
        foreach ($prop in $ADOprops) {
            #Write-Output "Looking at property $prop"
            $fl = "(&(objectclass=attributeschema)(ldapdisplayname=$prop))"
            $linked = (Get-ADObject -LDAPFilter $fl -SearchBase $snc -pr linkid).linkid
            #Write-Output $linked
            If (($linked -eq $null) -and (($obj.$prop).count -gt $queryCount)) {
                Write-Output "----------------------------------------------"
                Write-Output "AD Object ""$($obj.DistinguishedName)"""
                Write-Output "has attribute ""$prop"" with a count of $($obj.$prop.count)"
            } # end if
        } # end foreach
} # end foreach

Feedback is, as always, very welcome!

 

I upgraded a client’s CAS servers recently from Exchange 2007 Service Pack 2 Update Rollup 5 to Service Pack 3 Update Rollup 13 in preparation for upgrade to Exchange 2013.  Following the restart after the Update Rollup had completed I found I could not log into OWA.  Instead I got a blank page with a URL similar to the one shown below.

https://MyCAS/owa/auth/logon.aspx?url=https://MyCAS/owa&reason=0

I found several suggestions for what might be the problem on the web, but the one that worked for me was to run the UpdateOwa.ps1 Powershell script in the Bin folder under the Exchange installation path.

It was required on both CAS servers, so at least it was consistent :-)