The problem is that AutoFill will only ask to remember account information if it is enabled in Settings -> Safari, and if you visit the login site in Safari itself instead of the logon screen (which is obviously also Safari, but not advertised as such).

The trick is then to trick your Wifi in not triggering in showing the logon form, but have the Wifi connected and surf to any site to get the logon screen working.

You can do it by disabling Auto-logon on your Wifi:

1. Disable Auto-Login in WiFi settings for given network
   • go to Settings app
   • select “Wi-Fi”
   • tap on the blue “>” icon to the right of your network
   • disable “Auto-Login”
2. Start Safari and surf to any site. The Wifi authentication page should pop up. Log in manually. If AutoFill is enabled including “Names & Password”, logging in prompts you to remember the login.
3. Re-enable Auto-Login for your network (same as step 1, but enabling “Auto-Login”)

Added february 7, 2012:

Ryan C. was kind enough to let me know by email that the above procedure also helps you out when your password has changed and you need to reapply the new password in the phone’s memory. As the Auto-Login is enabled, it will never kick in the procedure to recognize you tapped in a new password, and you will have to retype the new password over and over. By going to the 3 steps above you get again a prompt to save your updated password, and you’re then set to go with your new password.

One of the new features is Siri, an AI assistant which uses voice to interact with me as an user, and the backend of what is my iPhone: reminders, my calendar, my contacts, and the internet.

Now, interacting with voice is not something entirely new. My car’s hifi and satnav system supports a basic level of voice commands to call people from my contact list, and even my Garmin Zumo 660 which I use on my motorcycle supports it.

Whereas in my car the voice commands are processed by the car, however, Garmin’s Zumo 660 uses the voice support of my phone. So if I had a phone which did not support voice commands, I’d be out of luck. But Garmin’s Zumo 660 specifies in the documentation that this voice is only limited to calling people: you shout their name in the microphone, and your phone should know what to do: call the contact who’s name you shouted.

It all goes a bit haywire on the iPhone 4S though: instead of simple voice commands, the speech button on the Garmin Zumo 660 starts up Siri on the iPhone and Siri will accept voice commands.

That’s the good bit. The bad bit is that if you’re not quick enough giving your voice command and receiving an answer from Siri, the Zumo will end the voice dialing phase with an error saying that the phone does not support it, breaking off your dialogue with Siri.

So the basic premise is: Yes, Siri can work for you on your motorcycle, but Garmin needs to modify their firmware to recognize and treat Siri differently than any other voice dialer system.So I just received my iPhone 4S. I love it.

One of the new features is Siri, an AI assistant which uses voice to interact with me as an user, and the backend of what is my iPhone: reminders, my calendar, my contacts, and the internet.

Now, interacting with voice is not something entirely new. My car’s hifi and satnav system supports a basic level of voice commands to call people from my contact list, and even my Garmin Zumo 660 which I use on my motorcycle supports it.

Whereas in my car the voice commands are processed by the car, however, Garmin’s Zumo 660 uses the voice support of my phone. So if I had a phone which did not support voice commands, I’d be out of luck. But Garmin’s Zumo 660 specifies in the documentation that this voice is only limited to calling people: you shout their name in the microphone, and your phone should know what to do: call the contact who’s name you shouted.

It all goes a bit haywire on the iPhone 4S though: instead of simple voice commands, the

Click here to view the embedded video.

Click here to view the embedded video.

We traveled in 2 days, with a stop in Kingston, ON for burgers. We stayed overnight in Four Points by Sheraton in Lévis, near Quebec City, and drove on to Shediac, NB with stops at the visitor’s centre on the QB-NB border and Pirate de la Mer fish restaurant in Edmunston, NB, a few kilometers past the border.

What I missed in the documentation of MDT 2008 is a way for me as a consultant to set up an MDT environment with sources, settings and images, and being able to deploy these sources, settings and images to a client’s MDT.  This because most clients have similar set up environments, with all similar starting sources.  It is no use to send the first half day of your consulting job importing sources you have already imported numerous times for other clients and yourself.

Ben Hunter described in 2007 a procedure he called hydratation, where he set up an BDD 2007 environment and uses this source environment to hydrate client environments with sources and settings.

This procedure is remarkably similar to what is needed to set up an MDT 2008 environment.  Once your MDT 2008 environment is to your liking, you can simply copy the Distribution folder on the newly created Distribution folder at your client’s MDT environment.  Make sure to change all product keys and customer specific data, and recreate the builds necessary.

This procedure is also useful if you want to copy the customer’s MDT onto another machine.

1. Install MDT 2008 and the Windows Automated Installation Kit (WAIK)
2. Create a new distribution share directory
3. Copy the files from your source distribution share directory over to your newly created distribution share directory
4. Set up the necessary deployment points, copying the settings from your source environment

Quick picture of my wife’s progress.

[pictobrowser wooter 72157616537379553]

I did in 2007, and never really thought of it until I ran into the following article 1006764 on the VMWare knowledge base.

The cause is very simple, and so is the solution: Member servers and clients have, just like users, accounts with passwords. If set up like this, these passwords are reset every set period. If you revert a machine back to an old snapshot, chances are that the password stored in the snapshot is not up to date with the password stored in Active Directory, and hence, Active Directory does not allow the machine to log on again.

Ever run into a problem where you revert a domain member server or Windows XP domain client toa previously taken snapshot, and when trying to log on the domain, the logon fails?

I did in 2007, and never really thought of it until I ran into the following article on the VMWare knowledge base: http://kb.vmware.com/selfservice/viewContent.do?externalId=1006764&sliceId=1

The cause is very simple, and so is the solution: Member servers and clients have, just like users, accounts with passwords. If set up like this, these passwords are reset every set period. If you revert a machine back to an old snapshot, chances are that the password stored in the snapshot is not up to date with the password stored in Active Directory, and hence, Active Directory does not allow the machine to log on again.