iPhone native twitter app is not displaying mentions under the @connect tab

Recently my twitter stopped updating mentions under the @connect tab in the default iPhone twitter application. Initially I thought it was just me but after a quick google search I found a number of users were experiencing the same problem.

After first trying to restart and then playing with a number of settings I was unable to resolve the problem, but the following process worked.


The Fix

1. Open the Settings menu.

2. Select Twitter.

    

3. Click on the account that is causing you a problem, in my case it is "@teamau"

4. Click "Delete Account". This doesn't delete your twitter account, but just clears the account from your iPhone.

5. Click "Add Account" and re-add the account you just deleted.

Voila, your @mentions should be working again!

Connecting to Lync Mobility without autodiscover DNS

Recently the long awaited release of Lync 2010 Mobility pack hit the web along with clients for Android, Windows phone and the iPhone. The setup process is a little convoluted, as with anything Lync related, but is fairly straight forward none the less.

We deployed the mobility pack with the idea of giving key staff access to the Lync client within our network boundaries. This process would involve manual installation and configuration of the Lync client on these phones and we have a tricky split-brain setup, so we purposely didn't configure the autodiscover DNS.

When we configured a test client with what we through was the correct internal URL, it just hung forever at the signing in screen. Furthermore the great logging tool for the iPhone client gave us no indication of what the problem was. Everything in the log seems normal until the last line.

Lync[231:707]  is not a valid email address.

We tested the configuration using the Test-CsMcxP2PIM powershell script which returned successful, no problems there.

The Resolution

I feel so stupid, the problem was the URL we were entering into the manual internal address field on the iPhone client. After digging for a long time we finally found the URL buried in a Microsoft TechNet article while looking for something else.

https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

The above address is the correct URL to enter into your iPhones "internal discovery address" field if you are not using autodiscover services. As soon as we changed the configuration of the iPhone client, everything worked perfectly. This is as much a note to remind myself how stupid I am as anything.

How to replace Apple Macbook Air 2010 3.1 SSD with MX-Katana and performance analysis

I love my Macbook Air 2010 3.1 11" for its portability and size but the stock Toshiba SSD is lack luster in performance and plus I only have the 64GB version. After checking out my available upgrade options I got my hands on the Mach Xtreme MX-KATANA 128GB.

For those not familiar with Mach Xtreme, they are a manufacture focussed on the enthusiast sector and high end. I reviewed their MX Armor 2000 9-9-9-24 2x4GB memory kit in a shoot out for APC earlier in the year and I was suitably impressed.



The Product

Name: MX-KATANA
Model: MXSSD2MKAT-128G
Maximum read performance: 275 MB/s
Maximum write performance: 225 MB/s
Sustained Write: 130 MB/s
IOPS: 25,000

Very impressive specifications for a notebook drive, lets hope my heightened expectations stay true in the performance analysis.

 

  

I was very happy to find the necessary screw drivers included in the package as Apple use a "5-Point Pentalobe" driver, which isn't exactly a screwdriver most people have in their collection.

The Installation

Before you begin, I suggest making a copy of your existing SSD with a tool like carbon copy cloner (CCC). If you use CCC to clone your SSD onto an external USB hard drive, after you have installed your new SSD you can boot from the USB clone and use CCC to clone the data onto your new MX-KATANA SSD.

I have created the below youtube video which details the complete process of removing the back cover, installing the new SSD and replacing the cover.

Here are some more photos of the installation process.

 

Benchmarks

I have decided to use XBench and QuickBench to benchmark the existing Toshiba SSD and the new MX-KATANA, this will allow me to directly compare the two.

I set QuickBench to 5 loops and for Xbench I reran and averaged the results over 3 complete runs.

Performance Analysis


Starting with the QuickBench (QB) average for sequential read, we see the KATANA take a small lead of around 10 MB/s, nothing spectacular but solid. Moving onto QB random write average and again we see a small margin of only 7 MB/s.

I also listed the 1024K random write, this is not an anomaly but a consistent result I see across all of my benchmarks. As the write size is increased the performance leans more in the direction of the KATANA.

Moving onto the XBench results we see a meagre 1% advantage to the KATANA in the disk test score results. In the un-cached write 4K results the stock Toshiba SSD actually takes a lead of around 9 MB/s, but the victory is short lived when the KATANA smashes it in large 256K read operations by 20%.

These results certainly give a clear indication that the KATANA is a great option for those using large cluster sizes, but who is? I don't know many people using anything bigger than around 8-16K, unless it is a dedicated drive for video/audio editing.

That being said if you are working with big files the KATANA will have big benefits for you, but for everyday use you can expect around a 10% performance gain over the stock SSD.

Apple IOS 10.6 domain bind problems - This computer is unable to access the domain controller for an unknown reason

We have had a number of Apple IOS 10.6 machines lose connectivity with the domain. This manifests itself as users not being able to login to the computer, the screen simply just shakes and doesn't allow the login.

In the past we have simply unbind the machine from the domain, then rebind the machine, problem solved. Unfortunately this time it was not as simple and we got a very generic error message that read "This computer is unable to access the domain controller for an unknown reason", great, that doesn't sound good.

Fortunately there are some more detailed logs we can look at, but first we need to enable the debug logging to ensure we capture all the important details of the failure.


Enabling the directory services debug logs

1. Open a terminal window

2. Elevate to root privledges by typing

sudo su root

3. Type the following commands

killall -USR1 DirectoryService

tail -f /Library/Logs/DirectoryService/DirectoryService.debug.log

Now the debug logging is enabled, and the tail -f command follows the log to display the latest information live on the screen.



Detecting the problem

When we put our Directory Service into debug logging and inspected the logs, we found the following errors straight after attempting to bind the computer to the domain.

Active Directory:       Password verify for administrator@TEST.INTERNAL failed with error -1765328230
Client: Directory Utilit, PID: 222, API: dsDoPlugInCustomCall(), Active Directory Used : DAR : Node Ref = 33556364 : Request Code = 84 : Result co$
Plug-in call "dsDoPlugInCustomCall()" failed with error = -14090.
Port: 20831 Call: dsDoPlugInCustomCall() == -14090

What didn't help resolve the problem

• Deleting the computer account in active directory, then unbinding/rebinding
• Unbinding and rebinding to the domain
• Recreating a fresh computer account in active directory and then rebinding
• Ensuring the IP/Host lined up correctly with the domain DNS entries
• Restoring a previous backup (obviously the computer password had changed in the previous backup, but restoring the backup then rebinding the machine to the domain also failed)

Fixing the problem

After doing some research I found a number of people that were experiencing the same issue and fortunately the fix is fairly easy, but hidden deep! The Kerberos config is located in /var/db/dslocal/nodes/Default/config/ and by deleting these configs, we can clear out any problematic settings and regenerated them.


1. If your system is still bound to active directory unbind it. This can be done in the Directory Utility, then clicking on directory services, and unbinding active directory.

2. Open a Terminal window

3. Elevate to root privledges by typing

sudo su root

4. Delete the Kerberos config, you can do this by typing.

Rm -f /var/db/dslocal/nodes/Default/config/Kerberos*

5. Reboot

6. Rebind to the domain. Again this is located in the Directory Utility.


This is a relatively easy fix, but without knowing exactly where to look, it can take a long time to find!

Apple IOS 10.6 logon scripts

In a windows active directory enterprise environment logon scripts are critical to delivering services to users as they log on.

Unfortunately the login hook method that has worked so well in previous IOS versions is not working in 10.6, but don't fear, there is a new method based on the launch daemon that we can utilize.

In my environment I want to deliver a smbfs based network drive hosted on a windows file server and create some directories as the user logs in, this is the method I used.

1. Create a launchd plist that contains the path of the login script I plan to use. I do this by creating a .plist file in the /System/Library/LaunchAgents directory. My configuration file was called logonscript.plist and read as follows.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>Label</key>

<string>logonscript</string>

<key>LaunchOnlyOnce</key>

<true/>

<key>ProgramArguments</key>

<array>

<string>open</string>

<string>/usr/bin/logonscript</string>

</array>

<key>RunAtLoad</key>

<true/>

<key>ServiceDescription</key>

<string>logonscript</string>

</dict>

</plist>

In short all my configuration file does is launch /usr/bin/logonscript on user login, you can change that

<string>/usr/bin/logonscript</string> to anything you want.

2. Next I simply create my logonscript, my script read as follows.

echo Logging you on..
echo -

echo Connecting public drive..
mkdir ~/Desktop/public
/sbin/mount_smbfs //fileserver.blah.internal/public ~/Desktop/public
echo done..
echo -

echo Logon complete... You can now close this window..

 

While my script is very simple, the power of bash scripting would allow you to do a large number of operatings during this logon.

3. Of course lastly we need to modify the file to be executable

chmod +x /usr/bin/logonscript

You are all set, now your users can logon and automatically map the required network drives as long as you have already binded the system to active directory.

Apple IOS 10.6 SSO printing with Active Directory

Integrating Apple desktops into a windows active directory infrastructure can be extremely hard and one of the most difficult aspects is enabling single sign on (SSO). In a windows world nearly all services are single sign on and it can be inconvenient and annoying for users to have to continually enter their password.

I came across difficulties when I started to map network printers on an IOS 10.6 machine. When the printer authentication dialog appeared, the username field was already populated, but instead of being populated with the username it was populated with the users real name. This meant on almost every occassion when the popup appeared, the user left the username field alone and just entered their password resulting in a failure to print and lots of support calls to IT. The answer lies in a very simple switch we can use in combination with the scutil tool.


1. Open a terminal


2. Type the following to elevate your privileges to root.

sudo su root

3. We need to set the hostname of the system to the FQDN (fully qualified domain name), replace blah.domain.com with your actual FQDN, for example.

scutil --set HostName blah.domain.com

4. Next get a list of the printer queue names by typing the following.

lpstat -v

The list is shown as below.

sh-3.2# lpstat -v
device for PRINTQUEUE001_LibraryStudent_Kyocera400ci: smb://PRINTQUEUE.blah.internal/LibraryStudent-Kyocera400ci
device for PRINTQUEUE_LibraryStudent_Kyocera400ci:: ///dev/null

The printer queue name in this example is PRINTQUEUE_LibraryStudent_Kyocera400ci



5. Now take the printer queue name(s) and run the following command, replacing the "PRINTQUEUE_LibraryStudent_Kyocera400ci" with your queue name. You need to repeat the process for every printer queue for which you want to enable SSO.

 

lpadmin -p PRINTQUEUE_LibraryStudent_Kyocera400ci -o auth-info-required=negotiate

It really is as easy as that, now the next time your users go to print to any of those Active Directory printer queues you have enabled SSO on, they will not even be prompted.