I'm a pretty carefree guy, experimenting with all kinds of weird applications from dubious sources. The domain and the network is pretty well secured, but my virtual lab computers are like people in the old west; unregulated and easily killed off if they become to unwieldy.
Still, when something suspicious happens I wan't to know why, because of course I wan't.
Some time ago the following dialog suddenly popped up when I logged in to my work computer;
What? No, I would not like to allow Regedit.exe to make changes to my device. Searching through the startup locations with Sysinternals excellent Autoruns didn't reveal anything and concurrent logons did not start Regedit.exe. Probably, it was launched by the RunOnce registry key. Difficult to troubleshoot when the traces are gone.
Weeks later it appeared again! What program is causing this? Why does it want to start Regedit.exe? How do I find out when it only happens once every month or so? None of my coworkers have had the same experience and even though I have a black belt in Google-fu searching the web was hard, only resulting in how to use Regedit. I know this already!
Then it appeared on my clean virtual lab computer, not in any way related to my domain joined work computer. Luckily I had just done a snapshot of it and Regedit.exe wanted to start every time I restored. Finally some progress! Using my incredible skills I finally found the culprit using Procmon, the greatest tool of all time;
Indeed it was a RunOnce registry key and the name of it, "Application Restart #1" is the clue. Since some version ago (who knows which, versioning sucks) Windows restarts select applications that were running when the computer was shut down. Not only during forced restarts from updates, but when you manually shut down the computer. Apparently I am not very good at closing programs before shutting the PC down.
Not all programs are restarted and how Windows decides this is still a mystery to me. It's a badly documented feature with a badly thought through workaround. This is what Microsoft Answers says about it.
Regardless, Regedit.exe, or any program requiring elevation, should not be started automatically!
Or is it requireing? Require-ing? Reqiruing? My Google-fu might not be as advanced as I thought.
A diary of a frustrated application manager and the adventurous world of application testing, packaging and deployment.
Visar inlägg med etikett troubleshooting. Visa alla inlägg
Visar inlägg med etikett troubleshooting. Visa alla inlägg
tisdag 20 mars 2018
Application restart #1
Etiketter:
consent.exe,
google,
Microsoft,
Procmon,
regedit,
regedit.exe,
registry,
requireAdministrator,
restart,
security alert,
Sysinternals,
trouble shooting,
troubleshooting,
uac,
Windows,
windows security
torsdag 28 december 2017
Installation failed because reasons
Sometimes installations fail. Often, the reason for failure is logical and easily found in a log file, sometimes you just get an 1603 with no indication whatsoever what went wrong.
And sometimes the install fails by design. A retarded design.
Solid Works 2016 installs Microsoft SQL Server 2008, Microsoft SQL Server 2012 and Microsoft SQL Server 2014.
I think most people see a probable cause for disaster right there. But surprisingly it usually works.
Unless your organisation has done the rare but sensible and rational thing and set a password policy:
As it happens, Microsoft SQL Server adheres to the group policy dictating the password policy for the domain.
There are workarounds found when googleing, but they either require disabling the password policy or modifying the way the database is created. Neither of these methods might be possible for an unattended install from a third party vendor.
Mostly because I don't feel like talking to the vendor, nor to my collegues managing the domain.
So here is how you install an SQL instance without supervision, without modifying the install and without modifying the domain:
; Removing password-requirements with secedit:
RunWait('secedit.exe /export /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)
FileCopy(@TempDir & '\sectmporg.cfg', @TempDir & '\sectmpcpy.cfg',1)
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","MinimumPasswordLength","0")
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","PasswordComplexity","0")
RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmpcpy.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)
; **********************
;
; THE INSTALL GOES HERE!
;
; **********************
; Restoring password-requirements:
RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)
And sometimes the install fails by design. A retarded design.
Solid Works 2016 installs Microsoft SQL Server 2008, Microsoft SQL Server 2012 and Microsoft SQL Server 2014.
I think most people see a probable cause for disaster right there. But surprisingly it usually works.
Unless your organisation has done the rare but sensible and rational thing and set a password policy:
As it happens, Microsoft SQL Server adheres to the group policy dictating the password policy for the domain.
There are workarounds found when googleing, but they either require disabling the password policy or modifying the way the database is created. Neither of these methods might be possible for an unattended install from a third party vendor.
Mostly because I don't feel like talking to the vendor, nor to my collegues managing the domain.
So here is how you install an SQL instance without supervision, without modifying the install and without modifying the domain:
; Removing password-requirements with secedit:
RunWait('secedit.exe /export /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)
FileCopy(@TempDir & '\sectmporg.cfg', @TempDir & '\sectmpcpy.cfg',1)
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","MinimumPasswordLength","0")
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","PasswordComplexity","0")
RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmpcpy.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)
; **********************
;
; THE INSTALL GOES HERE!
;
; **********************
; Restoring password-requirements:
RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)
Code is AutoIt, but I'm sure you figure it out in any language.
Etiketter:
deploy,
deployment,
exit code,
exit codes,
install,
installation,
Microsoft,
password,
password policy,
policy,
silent install,
sql,
sql server,
trouble shooting,
troubleshooting,
unattended,
windows security
tisdag 28 november 2017
Did you find this article helpful
Etiketter:
article,
help page,
helpful,
troubleshooting
Prenumerera på:
Inlägg (Atom)



