Quantcast
Channel: Comments for Stefan Goßner
Viewing all articles
Browse latest Browse all 3196

Comment on Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE by Alex LokNar

$
0
0

Hi Stefan,

I found this step important because it invokes below methods for each Service Application (strictly speaking – assembly class) found under reg key HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS\Services (around 40-50 subkeys in 2013 farm):
(SPService).Update()
(SPServiceInstance).Update()
(SPServiceProxy).Update()

I don’t have the concrete example of CU which requires it, but I can imagine some scenarios where it may be required.
For example, many Service Applications register Health Analyzer Rules in (SPService).Update() method: SPHealthAnalyzer.RegisterRules(Assembly.GetExecutingAssembly()).
If product team decide to implement new rule or change, let’s say, schedule for existing – it won’t be updated. This one is not that critical.
But below services have more important stuff in Update() method:
AppManagementService: CreateLicenseRenewalTimerJob
SessionStateService: RefreshWebConfigModifications
StateService: StateServiceExpiredSessionJobDefinition.EnsureJob
DiagnosticsService: DiagnosticsService.PushToRegistry, CreateTimerJob
As potential issues: missing new Timer Job, not pushed web.config changes for Web Application, missing new or changed registry key/value on server.
Some services don’t have anything in Update() method, so it’s OK to skip it for them.

Just knowing this, I would advise adding “services -install” param to PSConfig after CU installation. Especially when we have major changes in CU like new Cloud Search SA.
Described above could be one of the reasons why this param included in PSConfigUI on Upgrade step.


Viewing all articles
Browse latest Browse all 3196

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>