"It's not what you can do, it's what you can get done."

Monday, September 30, 2013

"the trust relationship between this workstation and the primary domain failed" better fixes

From http://www.implbits.com/about/blog/tabid/78/post/don-t-rejoin-to-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/default.aspx

This problem can be caused by various circumstances, but I most commonly run into it when I reset a virtual machine to a system snapshot that I made months or even years before.  When the machine is reset, it is missing all of the automatic password changes that it executed against the domain controller during the intervening months.  The password changes are required to maintain the security integrity of the domain.

The trick is to reset computer account password, use netdom.exe or powershell.

netdom.exe resetpwd /s: /ud: /pd:*

Reset-ComputerMachinePassword [-Credential ] [-Server ] 

Monday, May 20, 2013

Nice windows GUI git/mecurial client: SourceTree (By those fine Atlassian folks)

Seems to co-exist nicely w/ TortoiseGIT as well.

Thursday, January 31, 2013

WPKG - Open Source Windows software deployment option

Here's a deployment option/ Partial-Group Policy replacement that doesn't get enough love:

http://wpkg.org/

From the site: WPKG is an automated software deployment, upgrade and removal program for Windows.
It can be used to push/pull software packages, such as Service Packs, hotfixes, or program installations from a central server (for example, Samba or Active Directory) to a number of workstations.
It can run as a service to install software in the background (silent install), without user interaction.
It can install MSI, InstallShield, PackagefortheWeb, Inno Setup, Nullsoft, other software installers or .exe packages, .bat and .cmd scripts and similar: no more repackaging to perform software installation.
WPKG is open source software.

Wednesday, July 11, 2012

Google Update error 0x8004070 - Solved!

Error 0x8004070 when installing the Music Manager, which actually kicks off a GoogleUpdate.exe process.

Lot's of people have seen this error with various google products, I tracked it down to C:\Users\USERNAME\AppData\Local\Google\Update\ - had to kill active GoogleUpdate.exe process, then deleted whole folder. Success!

Tuesday, March 20, 2012

Local Update Publisher (Software deployment via WSUS)

This is a quickstart tutorial/demonstration of Local Update Publisher

"Local Update Publisher allows system administrators to publish their own updates to Windows Server Update Services using local publishing."


Pros:
Consolidates management and storage (one console, minimal Group Policy fiddling, no separate fileshare.)
Users can install updates on their schedule and/or admins can force schedule.

Cons:
Relies on a (small?) 3rd party project. (Though open-source, and using an official Microsoft API.)
Can't assign or offer to users, only per machine.


This tutorial assumes you have a working install of WSUS, and a basic knowledge of .MSI packages.

Remember everything is stored on your WSUS server, LUP is "just" a gui that talks to it, similar to the WSUS admin console. So download and install the EXE,  run it (you will need to "Run as Administrator"), point it at the WSUS server ("Localhost" if you're on the server, in our case "guard.ourdomain.com", port 80, no SSL for now), and go!

To publish:

First, acquire your MSI. In this example, we'll use the Frontmotion - supplied package of Firefox.

Select Tools -> Create Update. Point it at your .MSI. Confusingly, you *DON'T* provide the "MSI Path". (This is only if it is contained in an .EXE).

LUP (WSUS?) requires a Vendor and Product to be defined. Fill in any other details you think are relevant.(I like to include the version number in the name.)



You can then click through the next few screens, accepting the defaults for now. (These let you write more complex rules, to only target x64, for instance.) Click "finish". You'll get a progress window as it re-packages it for WSUS and uploads it the server.

Notice in this example there are now two versions of the package. Be sure to retire/remove the old version, or else clients will do weird things, i.e. continually install one then the other in the case of Firefox updates.)

Now, we just approve this update (in this case, only for the METRO-TEST group:




Now to see the results of our labor, first we have to assign our testing machine to the METRO-TEST WSUS group.Open up the WSUS admin console, find your target machine(s), right-click and give them membership the appropriate group.


From the LUP wiki:
"The WSUS clients have a locally stored cookie that stores the groups that the client is associated to. Until that cookie expires the client will not create a new one. This means that if you add clients to a group and then immediately try to force a client in that group to detect updates it will likely not find updates you have approved for your new group. You can either wait an hour or force the cookie to expire by running wuauclt with the /resetauthorization flag."

Once I did this, then re-ran "Check for updates" (CLI version: "wuauclt /detectnow"). Looks promising...







Now, go forth and publish!