windows guru needed.

[timwilky]

My problem is a rogue microsoft patch that kills an application.

The PC is locked down by all sorts of policies and patching is imposed by our security team somewhere in Europe.

Although they now no longer apply the rogue patch, if it is embedded within other patch sets it gets in.

I then have to spend days waiting for someone with admin rights to remove the patch, until next time. Other wise we try to con the patch system by copying the correct working DLL files back in place and rebooting the PC. The patch system thinks it is still in place. (For a while)

The user is not happy with this and wants the problem resolving once and for all. When the patch is in place he cannot do his job. (A materials properties database system) The application does not run, does not give an error, simply dies. A few references on the net to the patch and application problem elsewhere.

The simple solution would be on reboot, the correct DLL were copied into place. However, that script would need to run before logon and before the system recognised the DLL files that were in place.

So is it possible? I guess I would need to stick the script reference somewhere in the registery to run early in the boot process. Where?

[andrewsmith]

Tim do you know what patch it is?

I'm sure you can do it from the registry to kill the patch on boot. Usually changing it to 0 instead of 1 or removing the HKEY (if it is one). I've done it with the XP genuine check and never had an issue. I'm having a look for the how to I used.

[Mauler]

As a workaround you could boot into Safe Mode, replace the DLL files with the known good'uns, and then alter the security properties on those files so that the 'SYSTEM' user account has read-only access. In theory it should stop the OS from replacing the files but I don't know of any side-effects of doing that.

[Trickster2445]

Get me the patch name and I will write you a reg script that you can run remotely for him. I assume he does not have regedit access? If he does you can pop in his desktop and he just clicks it.

I doubt very much you would be allowed to do via his site container logon script without a change request...

To be fair, this is a job for your 3rd line to implement a fix for really.

Another way would be to have your packagers create an uninstall software group.

Do you use sccm or AD for deployments?

If sccm I assume its 2007 which sucks...

If you use 2012 just create him a separate wim file for his image to always block that patch and do a fresh pxe deployment mate.

[timwilky]

The patch is KB2506212 it replace the mfc42.dll and mfc42u.dll files with versions that fail to run the SCO xvision server.

The user has no rights whatsover.

I don't know what we use for patching, for deployment we currently use alteris and are in the process of moving to bigfix.

Because this is a single user in a company of 60,000 PCs the support organisation have no interest in spending any time beyond saying we need to get a software update from a vendor who say remove the patch and it works.

I have a tame admin I normally phone and get him working on the fix. Just last week both of us were away when the brown smelly stuff hit the fan.

35 years in IT as a software developer, system manager on vax, solaris etc. systems integrator/architect. Now a project manager for the IT organisation and the user rights administrators will not give me admin access to fix problems because I am not employed as a windows administrator, so submit a request and wait.

[Trickster2445]

Sucks to be you lol. I am ex desktop and now a project manager but I kept my ADM account teehee.

[jambo]

You could put in a startup script in AD group policy that only affected this machine and copied those files on boot up.

That is, however, an ugly hack as if these files are ever replaced by another patch that'll be partially rolled back out on boot until the end of time causing unknown behaviour.

If you're using SSCM or similar (with that many machines I'd be shocked if you're not using something similar) your support bods can put him in his own patch release group and block that one patch from being deployed to his machine. Takes nearly no time, and other machines used with the same software can be dropped into the same group in about a minute.

The 3rd party should not be demanding a security patch is removed, as if they're writing to the API properly they won't need this done. However, having worked in IT for a while I'm aware this is idealistic and not always practical.

Jambo

[fizzwheel]

If you're using SSCM or similar (with that many machines I'd be shocked if you're not using something similar) your support bods can put him in his own patch release group and block that one patch from being deployed to his machine. Takes nearly no time, and other machines used with the same software can be dropped into the same group in about a minute.

Thats what I'd do. If they are deploying patches with WSUS which is an option in a large organisation ( thats how I manage our estate ) its easy enough to do and involves not needing admin rights or running scripts / regedit stuff on startup.

We've had this before where the developers exploited a security loop hole that then Microsoft released a patch for which stopped our in house application from working... so similar scenario that you have.

Your software Vendor should really be sorting this out as I bet you are not the only customer they have issued this advice to...

[flymo]

A slightly different approach involves modifying the environment that this particular application runs within. You can create an application shim http://technet.microsoft.com/en-us/library/dd837644%28v=ws.10%29.aspx
so that, when your application requests that dll file, it can be redirected to an alternate copy in a different folder.