Hulp nodig bij sccm uit van 1803 build upgrade.

[ReZpie]

Goedemorgen medeforummers,

Ik zit met een probleem, en hoop dat jullie mij kunnen helpen
Ik moet er bij zeggen dat ik niet heel veel verstand heb van sccm en dat onze systeembeheerder die daar over ging het bedrijf heeft verlaten. Ik ben werkplekbeheerder, maar het zou mij enorm veel werk uit handen nemen als ik deze issue kan fixen.
Onze clients in de enterprise willen sinds windows build 1709 niet meer upgraden..Ik wil nu alle clients brnengen naar de 1803 build maar dit werkt niet meer.
Wanneer ik een client in de AD groep zet krijg ik het volgende:
Ik krijg verder geen meldingen bij compliant/error etc..
Weten jullie waar ik moet zoeken?

Alvast bedankt!

[ Voor 3% gewijzigd door ReZpie op 26-11-2018 21:21 ]

[Dennism]

Aan de hand van alleen dit screenshot valt er niet veel te zeggen, is bijvoorbeeld de juiste versie deployed? Wat zijn de "rules" van het service plan qua deadlines / availability e.d. gecombineerd met de maintenance windows van de betreffende machines. Als er geen passende maintenance windows zijn bijvoorbeeld voor die machines en ze mogen niet buiten maintenance windows om installeren dan zal er bijvoorbeeld maar weinig gebeuren.

Kijk dus eens naar het service plan, de properties van de deployment e.d. om te kijken wat daar staat. Ook heeft SCCM zeer uigebreide logging waar je van alles uit kan halen. Misschien eens wat tijd in steken, als werkplek beheerder kan een tool als SCCM je zeer veel werk schelen mits je weet hoe er mee om te gaan en hoe het in te zetten.

[ReZpie]

Hoi Dennism,
B
edankt voor je reactie. Ik ga mij er in verdiepen, en ik zal even zoeken waar ik die log kan vinden.

Ik heb ook nog even wat screens gemaakt van de settings van het service plan.

[ Voor 27% gewijzigd door ReZpie op 06-02-2019 21:22 ]

[Dennism]

ReZpie schreef op donderdag 6 september 2018 @ 12:48:
Hoi Dennism,
B
edankt voor je reactie. Ik ga mij er in verdiepen, en ik zal even zoeken waar ik die log kan vinden.

Ik heb ook nog even wat screens gemaakt van de settings van het service plan.


[afbeelding]

Ik zou initieel zeggen: zet ter test eens aan waar nu staat "hidden in software center" naar iets van "show in software center"

En dan die 2 vinkjes daaronder ook aan, zodat ie na de deadline mag installeren en rebooten buiten een maintenance window.

Op deze zou je als er geen andere issues zijn dan het ontbreken van een maintenance window in software center de installatie handmatig moeten kunnen starten.

Maar zou deze ook na enige tijd automatisch moeten starten.

Het kan echter zijn dat er ook andere issue's zijn, dan is echter zonder logging lastig te achterhalen.

[MAX3400]

Over welke SCCM build gaat het?

Andersom; je kan ook 1 client handmatig updaten, image capturen en als basis gebruiken voor volgende uitrol.

[Dennism]

MAX3400 schreef op donderdag 6 september 2018 @ 17:52:
Over welke SCCM build gaat het?

Andersom; je kan ook 1 client handmatig updaten, image capturen en als basis gebruiken voor volgende uitrol.

In ieder geval 1710, 1803 of 1806 (Co management is zichtbaar en zit in SCCM sinds 1710 tenzij ik me enorm vergis en pre release builds niet mee tel).

[ReZpie]

@MAX3400 Dit is de build van sccm


Ik heb net een client naast mij neergezet, die nog geen 1803 build heeft om te testen.

Versie client:





@Dennism Dennis, ik zal zo even kijken of ik handmatig kan updaten.


Alvast bedankt voor het meedenken.

[ Voor 11% gewijzigd door ReZpie op 07-09-2018 08:59 ]

[KrazyJay]

Sowieso zijn servicing plans in SCCM eigenlijk ruk. Hier hebben we ook geprobeerd met servicing plans te werken, maar zijn uiteindelijk omgeschakeld naar Task Sequences voor zowel upgrades als nieuwe deployments (icm de UDI/MDT). Het probleem is dat er bij elke major feature update weer iets veranderd wordt door Microsoft, deze keer zou het gaan om dual scan technet info.

Daarnaast is het altijd handig om te beginnen zoeken in client logs. Download om te beginnen (mocht je dat nog niet hebben) de Configuration Manager Toolkit op je eigen device, vooral CMTrace is een handige tool gebleken logs door te spitten. Op internet (zoals technet maar ook blogs van zelfverklaarde experts) kan je veel info vinden over welke logs waarop van toepassing zijn. Je hoeft daarvoor ook niet op de desktop van de gebruiker zelf te zitten als je je GPOs goed ingesteld hebt, dan kan je vanuit je eigen device naar \\hostname\c$\Windows\CCM\Logs. Eigenlijk begint het altijd bij de logs. Waarom gaat iets wel? Waarom lukt het niet? Logs logs logs.

Begin maar eens bij de StatusAgent.log, ScanAgent.log en PolicyAgent.log. Met CMTrace zie je gelijk de rode lijnen met errors, dat filtert makkelijker dan met Notepad te werken.

[Dennism]

KrazyJay schreef op vrijdag 7 september 2018 @ 09:08:
Sowieso zijn servicing plans in SCCM eigenlijk ruk. Hier hebben we ook geprobeerd met servicing plans te werken, maar zijn uiteindelijk omgeschakeld naar Task Sequences voor zowel upgrades als nieuwe deployments (icm de UDI/MDT). Het probleem is dat er bij elke major feature update weer iets veranderd wordt door Microsoft, deze keer zou het gaan om dual scan technet info.

Ben ik niet direct met je eens, goed ingerichte servicing plans werken uitstekend is mijn ervaring. Heb deze bij meerdere relaties naar alle tevredenheid draaien. Nieuwe machines imagen en gebruiksklaar maken gaat via task sequences, maar bestaande machines up-to-date houden heb ik eigenlijk nog nooit een issue gezien met serviceing plans.

Dual scan zal hier naar verwachting weinig mee te maken hebben, het issue daarmee is namelijk dat als dat verkeerd ingericht staat dat machines updates of upgrades kunnen installeren die niet zijn vrijgegeven in SCCM en ook op tijden dat je dit niet wil (buiten je maintenance windows). Iets waar TS geen last van lijkt te hebben, gezien het feit dat zijn machines juist niet upgraden

Ik denk nog steeds dat TS eerst moet gaan kijken of de machines die hij wil upgraden wel een maintenance window hebben. En verder uiteraard zoals we beide al aangeven, de logs doorspitten

[KrazyJay]

@Dennism Ik kan enkel spreken uit de ervaringen hier bij ons. Met servicing plans ging het gewoon niet goed. We zijn overgeschakeld van Ivanti naar SCCM, maar een aantal andere vestigingen zaten nog op oudere Windows 10 releases, zonder ook een FP update gehad te hebben. We hebben servicing plans opgezet, maar veel systemen gaven aan compliant te zijn tegen de 1709 en later de 1803 update, terwijl een 1511 dat natuurlijk niet is. Vele uren logs en tests later, zijn we overgeschakeld naar TS en sindsdien loopt het als een zonnetje. Maintenance Windows, distribution points, alles stond verder goed. Het leek wel met dual scan te maken te hebben, in combinatie met bepaalde GPO's gebeurde er gewoon niets.

Sowieso is het hebben van een maintenance windows wel noodzaak, maar, als het voorheen altijd goed ging bij de TS, dan is het raar dat het plots niet meer werkt zoals verwacht. Dan zou er iets gewijzigd moeten zijn aan de maintenance windows, of aan de eigenschappen toegekend aan de FP update, maar dat lijkt me sterk.

@ReZpie begin gewoon even bij de logs, vanuit daar kan al snel meer zichtbaar worden. Kijk ook even of je HTTPS gebruikt en of de certificaten niet verlopen zijn.

[ReZpie]

@KrazyJay Ik heb zojuist die toolkit op mijn eigen werkplek geinstalleerd. Ik zal er vandaag naar proberen te kijken en wat logs proberen uit te draaien bedankt.

[ Voor 4% gewijzigd door ReZpie op 07-09-2018 10:06 ]

[ReZpie]

Heren,
Sinds ik die 2 vinkjes heb aangeklikt lijk ik progressie te boeken op mijn test pc.
De client installeerd de software ook.


Test pc komt nu ook voor in het tabblad "In progress" Dit is al tijden niet zo geweest, elke keer kwamen alle pc's 100+) bij unknown
zoals screen:

Dus ik maak stappen, dank daarvoor!


Met name de ztl01 en 02 zou ik graag willen weten of en hoe ik daar achter kan komen wat daar fout gaat.

Ik ga ze nog even opnieuw toevoegen in AD om te kijken of dat nog wat uit haalt.

[edit] Ik ga daar die cmtrace installeren op de ztl's en kijken of ik er logs uit kan halen

[ Voor 11% gewijzigd door ReZpie op 26-11-2018 21:20 . Reden: verkeerd plaatje ]

[KrazyJay]

Je kunt CMTrace dus gewoon op je eigen computer uitvoeren en via \\WT7ZTL01\c$\Windows\CCM\Logs die logs openen. Enkel je firewallpolicy moet dat toestaan.

[ReZpie]

Slot

[ Voor 99% gewijzigd door ReZpie op 06-02-2019 21:23 ]

[ReZpie]

Iemand nog een idee toevallig?
Kan het ook met de versie van system center te maken hebben want die wilt ook niet updaten naar de laatste versie.

[Dennism]

ReZpie schreef op vrijdag 14 september 2018 @ 07:45:
Iemand nog een idee toevallig?
Kan het ook met de versie van system center te maken hebben want die wilt ook niet updaten naar de laatste versie.

Aan de versie zou het niet mogen liggen 1802 kan 1709 gewoon updaten naar 1803
Waarom wil SCCM niet upgraden van 1802 naar 1806 dan? Zou je moeten kunnen zien in de console of in de logs.

Het woord logs zal bij SCCM vaak langskomen, eigenlijk ieder issue kan je oplossen door de logs uit te pluizen en op basis daarvan het issue op te lossen, of om te zoeken naar de oplossing door bijvoorbeeld te zoeken op bepaalde foutmeldingen.