I've had this happen a few times now, not sure what causes it, but iCloud Photo Stream occasionally stops syncing on Windows 7 for me.

The way I have fixed it is to reset iCloud  by:

  1. stopping the Photo Stream process ApplePhotoStreams.exe using Windows Task Manager
  2. renaming the %APPDATA%\Apple Computer\MediaStream directory (i.e. C:\Users\username\AppData\Roaming\Apple Computer\MediaStream)
  3. log out and back in again
  4. restart iCloud (Start, type iCloud, press Enter) and re-enable Photo Stream.

Judging by this thread on the Apple Forums uninstalling and re-installing iCloud also seems to do the trick, but of you're reasonably computer savvy, my method may be a little bit quicker.

With any luck, the next version of iCloud will fix this issue.


If, like me, you are constantly wanting to just extract the files from a Windows Installer MSI file quickly, then this is for you.

My ZIP utility of choice 7-Zip appears to support extracting MSI files but in fact extracts all the various weird and wonderful binary streams in the MSI rather than simply just the actual files. Thankfully I stumbled across a Windows Installer switch today after typing msiexec /? that does the job perfectly: the /a “administrative install” switch, e.g.:

msiexec /a foo.msi /qb TARGETDIR="C:\TEMP\Foo"

So, what I’ve done is packaged this up as a little registry tweak that conveniently lets you do this by simply right clicking a file like so:


Copy and paste the following into a *.reg file and double-click it:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Classes\Msi.Package\shell\Extract MSI\command]
@="msiexec.exe /a \"%1\" /qb TARGETDIR=\"%1 Extracted\""

Hope that helps!


As part of our logon script we have a Windows Script Host script that was failing with “Provider: Unspecified error” (mmn, helpful) but only on some Windows XP machines.

The offending line of code looked like this:

rs = con.Execute("<LDAP://DC=example,DC=com>; (sAMAccountName="+ username +"); ADsPath; subTree")

After some trial and error the fix was this (see if you can spot the difference):

rs = con.Execute("<LDAP://DC=example,DC=com>;(sAMAccountName="+ username +");ADsPath;subTree")

Can you see what it is? No spaces after the semicolons!

Alternatively the SQL-like syntax also seems to be a bit more forgiving:

rs = con.Execute("SELECT ADsPath FROM 'LDAP://DC=example,DC=com' WHERE sAMAccountName='"+ username +"'")

It appears that with some later version of ADSI ADsDSOObject (or to give it its full title, the “OLE DB Provider for Microsoft Directory Services”) the query syntax strictness has been relaxed. In any case "Unspecifed error" appears to mean "Syntax error" in this case.


I tried to find some mechanism to get the current machine's NetBIOS domain name (the machine domain, not user domain), but couldn’t find anything in the usual places (e.g. System.Environment). If you want the fancy-schmancy Active Directory DNS domain then you can use Domain.GetComputerDomain().Name from System.DirectoryServices.ActiveDirectory, or another one that I stumbled across in Reflector was IPGlobalProperties.GetIPGlobalProperties().DomainName that lives in System.Net.NetworkInformation. But a simple way of getting the old-skool NetBIOS/LanManager-style machine domain name proved elusive.

Some googling suggested that WMI would provide the answer but I find WMI a little heavyweight, and not always reliable. The information is also probably in the registry somewhere, although I couldn’t find it after a cursory scan. The proper, supported way it would appear is to use the Network Management API. So my solution entailed P/Invoking to netapi32.dll.

If you’re after the same information I hope you find the code below useful. Once you've incorporated this in your project, just call the GetMachineNetBiosDomain method. It will return the machine's Workgroup name if the machine is not domain-joined.

UPDATE: Now works on 64-bit thanks to update sent by Rp Brongers.

using System;
using System.Runtime.InteropServices;
using System.ComponentModel;

class NetUtil
    [DllImport("netapi32.dll", CharSet = CharSet.Auto)]
    static extern int NetWkstaGetInfo(string server,
        int level,
        out IntPtr info);

    static extern int NetApiBufferFree(IntPtr pBuf);

    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
    class WKSTA_INFO_100
        public int wki100_platform_id;
        public string wki100_computername;
        public string wki100_langroup;
        public int wki100_ver_major;
        public int wki100_ver_minor;

    public static string GetMachineNetBiosDomain()
        IntPtr pBuffer = IntPtr.Zero;

        WKSTA_INFO_100 info;
        int retval = NetWkstaGetInfo(null, 100, out pBuffer);
        if (retval != 0)
            throw new Win32Exception(retval);

        info = (WKSTA_INFO_100)Marshal.PtrToStructure(pBuffer, typeof(WKSTA_INFO_100));
        string domainName = info.wki100_langroup;
        return domainName;


Recently Windows Vista has been refusing to show the Windows Firewall Settings dialog box and instead showing the ever so informative message: “Windows Firewall: Due to an unidentified problem, Windows cannot display Windows Firewall settings”.


No clues. Nothing in the Event Log. Nothing. Brilliant.

Well I had a brain wave this morning about what might be causing it. Thankfully it turned out to be right. I remembered that on our Windows Domain we have a few Group Policy settings that apply to Windows Firewall.


In this case the culprit was the “Define program exceptions” that had a few old entries for AVG 7.5 Network Edition. As we’d upgraded to AVG 8.0 recently the program paths were no longer valid, nor really necessary. So I removed them entirely and set the policy back to Not configured. To verify it worked I ran gpupdate /target:computer /force at a command prompt on my workstation and voila: the Windows Firewall Settings dialog box would now appear once more.


Group Policy for Windows Firewall is stored on client machines in the the Registry at:


So if you’re not on a domain and there are registry entries in this location that have been set for some reason, then adjusting them will have the same effect as changing the Group Policy. If you are on a domain then getting the Group Policy fixed is obviously the right approach.

Hope that helps you – leave a comment if it does.