Office365 Exchange Control Panel now has command logging for admins.

Help Button, Show command logging.One of my annoyances with Office365 administration tasks was that I could make changes to the interface but had no idea what commands were being run behind the scenes. This made creating scripts a frustrating trial and error attempt at finding the correct verbs to run.
However, this morning I stumbled under the Help/Show Command Logging option in the admin panel. This is similar to the Show command output that was available in the Exchange 2010 admin console that I used extensively in the good old on-premise days.

I have no idea how long this has been here but it really made my day.

Now if only the rest of the Office365 admin panels had the same functionality.

Fixed: Office 2010 installation with MAK key gives Error: Can’t decode PIDKey – Invalid digits! ErrorCode: 0(0x0)

After doing an administrative installation of Office Professional Plus 2010 for a client, I was trying to test the installation of office on a desktop machine but kept getting “Error: Can’t decode PIDKey – Invalid digits! ErrorCode: 0(0x0).” as the error message. I confirmed that the key was correct by doing a manual installation of the software and using the same product key that was successful. I was unable to find any useful pages on the internet with this error message so ended up logging a call with Microsoft Product Support to troubleshoot the installation.

Our troubleshooting steps were to remove the updates folder completely and try an installation – this worked so we knew the problem was in the updates directory. Recopying back the files from the extracted service pack 1 dvd worked successfully so the problem was either service pack 2 or the setup.msp file. I copied back the sp2 files and again the software installed successfully (note that having a virtual test pc makes these tests very easy. No uninstalling of office required!)  Again the installation was successful. I then copied the setup.msp file back into the updates directory and the installation failed again. As the configurations that are made in the setup.msp can either be set in the config.xml or group policy it was ok to proceed without using the setup.msp.

Full details of the log files and more information can also be found at the Microsoft forums where I posted the initial request for help.