Het grote kleine-SysOps-vragen topic deel 1

[Hero of Time]

Ah, altijd leuk. En via een browser is dat niet altijd even duidelijk te zien. Welke pipo had het ingesteld?

[lolgast]

Ah ja, het leed dat spaties heet Goed dat het is gevonden!

[Arfman]

Arfman schreef op maandag 24 augustus 2020 @ 13:07:
Iemand toevallig nog een goed, werkend tooltje of manier om een MBR disk (die tegen de 2TRB limiet aanloopt) om te zetten naar GPT? Alles wat ik vind is trialware en met mbr2gpt lukt het niet, die kan voor zover ik kan zien alleen systeempartities omzetten.

Uiteindelijk maar een nieuw 2.5TB volume aangemaakt en met robocopy alles overgezet ...

[jordeeeh]

Creep schreef op dinsdag 25 augustus 2020 @ 20:17:
[...]

Zucht, het was DNS. Er stond een spatie in de DNS-naam. Je mag een spatie invullen en opslaan en werkt blijkbaar eventjes, maar dan stopt het opeens na een paar dagen met werken.

[QaZ.]

Hero of Time schreef op donderdag 20 augustus 2020 @ 20:57:
Grotere bedrijven hebben vaak een apart management netwerk op z'n eigen vlan. Bij MKB is dat wat anders. Mijn werkplek kan dan in beide netwerken zitten, maar als je een gebruiker moet helpen en 'even snel' bij die management omgeving moet, is dat wat lastig als dat systeem niet in het management netwerk/vlan zit. En dus heb je management zaken in het 'normale' netwerk.

We hebben al VoIP gescheiden, maakt het makkelijker om het via een andere gateway/internetverbinding te routeren. En gasten wifi is ook al een ander vlan en verbinding.

Ik ben blij dat ik in de afgelopen 10 jaar dat ik in dit vak werk bij grotere bedrijven heb gezeten om af te kijken hoe zaken 'horen' en beter kunnen zodat ik het vergelijkbaar en naar eigen inzicht hier kan toepassen.

Daarom dat ik al jaren als 1e een management vm aanmaak met 2 nics waarvan ik alle management taken uitvoer, dan kan ik vanaf het hele lan snel overal bij.

[FREAKJAM]

Turdie schreef op donderdag 20 augustus 2020 @ 21:01:
[...]


In Azure AD heb je nu zelfs Azure AD Privileged Identity Management, als je een beheer rol nodig heb kun je voor een aantal uur aanvragen, voor high risk rollen zoals Global Admin kan je zelfs instellen dat het door iemand anders approved moet worden en dat degene die hem aanvraagt een ticket nummer moet invullen of een omschrijving waar hij/zij het voor nodig heeft. Ook al je toegang wil hebben tot bepaalde resources kun je instellen dat aangevraagd moet worden.

JiT/JeA principe. Zit trouwens ook gewoon in Windows Server 2016 trouwens.

[FastFred]

Ben bezig met een simpele backup inrichten. 1 map met daarin subfolders en bestanden. Die wil ik 1x per dag naar een netwerkschijf sturen. De betreffende map staat op de C: schijf van een werkstation.

Dat dacht ik mooi te doen met wbadmin. Maar

Een gedeeltelijke back-up van volumes wordt niet ondersteund op deze versie van Windows.

Geprobeerd op Windows 10 Home en Pro. Nu is de vraag, op welke versie van Windows wordt het wel ondersteund? Ik kan het niet vinden. Het commando en de nodige parameters zitten er wel in...

[ Voor 3% gewijzigd door FastFred op 01-09-2020 16:28 ]

[Hero of Time]

Windows Server 2012R2 iig zeker. Anders maar andere software gebruiken? Je zou een geplande taak met robocopy kunnen maken, al zal je dan zelf wat moeten doen qua retentie.

[Enforcer]

FastFred schreef op dinsdag 1 september 2020 @ 16:23:
Ben bezig met een simpele backup inrichten. 1 map met daarin subfolders en bestanden. Die wil ik 1x per dag naar een netwerkschijf sturen. De betreffende map staat op de C: schijf van een werkstation.

Robocopy en evt 7za om files te zippen...

code:

SET HH=%TIME:~0,2%
IF "%TIME:~0,1%"==" " SET HH=0%HH:~1,1%
SET YYYYMMDD_HHMMSS=%DATE:~10,4%-%DATE:~4,2%-%DATE:~7,2%_%HH%%TIME:~3,2%%TIME:~6,2%

SET ROBOCOPYARGS=/TEE /S /E /XO /COPY:DAT /R:1 /W:1 /V /A-:SH

SET SRCFOLDER="C:\Temp\Source"
SET DESTFOLDER="\\DEST_NAS1\Dest"

SET ZIPFOLDER="\\DEST_NAS1\Dest\_Zipped"

echo Step 1 of 2 - Delete older zipped backups from 365days (1year) ago
forfiles /p "%ZIPFOLDER%" /d -365 /c "cmd /c del @path" >nul 2>&1

echo Step 2 of 2- Backup & Zip
robocopy.exe %SRCFOLDER%\ %DESTFOLDER%\ %ROBOCOPYARGS% > %ZIPFOLDER%\Backup_%YYYYMMDD_HHMMSS%_log1.txt
7za.exe a %ZIPFOLDER%\Backup_%YYYYMMDD_HHMMSS%.zip %DESTFOLDER%\ >> %ZIPFOLDER%\Backup_%YYYYMMDD_HHMMSS%_log2.txt

[Turdie]

FastFred schreef op dinsdag 1 september 2020 @ 16:23:
Ben bezig met een simpele backup inrichten. 1 map met daarin subfolders en bestanden. Die wil ik 1x per dag naar een netwerkschijf sturen. De betreffende map staat op de C: schijf van een werkstation.

Dat dacht ik mooi te doen met wbadmin. Maar


[...]


Geprobeerd op Windows 10 Home en Pro. Nu is de vraag, op welke versie van Windows wordt het wel ondersteund? Ik kan het niet vinden. Het commando en de nodige parameters zitten er wel in...

Volgens kan wbadmin op client toch alleen maar hele partities backuppen, niet een enkele folder. Dan zullen je een andere oplossing moeten zoeken zoals PowerShell of Robocopy o.i.d

[downtime]

lolgast schreef op dinsdag 25 augustus 2020 @ 20:41:
Ah ja, het leed dat spaties heet Goed dat het is gevonden!

Die spaties, "smart quotes", m- en n-dashes en al dat geneuzel zijn een obsessie voor me geworden. Met name als je collega's hun documentatie in Word schrijven zitten daar nogal eens tekens in die Word zelf omgezet heeft naar de "mooie" versie. Of je kopieert een extra spatie, regeleinde of tab mee.

Als ik een commando copy-paste naar een command-prompt dan gaat het altijd eerst een Notepad venster in, ik pluis het uit op tekens die Word standaard omzet, zorg dat ik niets teveel selecteer, en dan kopieer ik het pas naar de prompt.

[FastFred]

Turdie schreef op dinsdag 1 september 2020 @ 20:32:
[...]


Volgens kan wbadmin op client toch alleen maar hele partities backuppen, niet een enkele folder. Dan zullen je een andere oplossing moeten zoeken zoals PowerShell of Robocopy o.i.d

Ja daar ben ik inmiddels ook achter ja Jammer, verder kan wbcommand alles wat we er mee willen.

[Turdie]

FastFred schreef op woensdag 2 september 2020 @ 09:46:
[...]


Ja daar ben ik inmiddels ook achter ja Jammer, verder kan wbcommand alles wat we er mee willen.

Misschien heb je hier wat aan
https://github.com/Seidlm/PowerShell-Backup-Script

Die kun je natuurlijk schedulen in de Task Scheduler, en wat variablen aanpassen naar eigen wens.

[ Voor 13% gewijzigd door Turdie op 02-09-2020 09:52 ]

[D_Jeff]

De case & info:
Recentelijk zijn er door mijn opdrachtgever 100 Dell desktops bestelt. Deze moeten in Intune (en daarmee in AzureAD) komen te zitten/hangen/******.

Hoewel de "Device based enrolment" nog de status preview heeft, zijn we overtuigd dat het prima werkt. (= getest met 12 surfaces)

1 van de voorwaarden om Device based te kunnen gebruiken, is dat er een Hardware / System ID in Intune staat. Helaas is het verzoek om een Intune CSV bij Dell Sale net te laat aangekomen.

De vraag: Is een handige manier om deze 100 machines snel in Intune/AzureAD te krijgen? (Zonder deze 1 voor 1 af te moeten met het befaamde "Get-WindowsAutopilotinfo" script)
Dank!

[noskill]

Geen idee of het aan al je eisen voldoet, maar je kan een provisioning usb stick maken en die in de PC stoppen tijdens de OOBE. Je krijgt dan meteen een deployment scherm.

https://docs.microsoft.co...lment/windows-bulk-enroll

[ralpje]

Eventueel is dit script van Ben Reader ook nog een optie.

[D_Jeff]

^^ Ah, leesvoer. Dank!

@ralpje Das het befaamde powershell script

[ralpje]

Nee, dit script is wel iets anders.
Wat je hiermee doet is op één device de autopilot XML ophalen en deze vervolgens integreren in je Windows image. Devices die je met dat image uitrust kijken dus naar die lokale XML en zijn klaar voor autopilot zonder dat je van elk device de hardware hash hoeft te harvesten om ze in Intune te stoppen.

[Hero of Time]

Als Outlook constant verbinding probeert te maken, maar mislukt om onbekende reden (volgens de logs en meldingen die de gebruiker krijgt), wat zou er dan aan de hand kunnen zijn?

Ik heb nu 3 gebruikers op onze RDS (2012R2, Office/Outlook 2016) die hier last van hebben. Eentje stuurde ik vanochtend naar een andere server en toen werkte 't weer, maar bij een van de andere twee die gisteren ook al issues had mocht dat trucje niet baten.

Nu heb ik vorige week de AAD sync naar O365 uitgeschakeld (in AADsync zelf, kon 't online in AAD zelf niet vinden waar velen naar verwijzen, de portal is verandert) en afgelopen weekend gebruikers naar een ander interne AD verhuisd, maar ik zou verwachten dat dat niet de oorzaak mag zijn. Ook omdat het bij de laatste van de gebruikers op z'n laptop wel prima werkt met W10 en Office 2016. De AADsync staat nog uit, ivm een laatste paar gebruikers die over moeten.

[pjlgt]

Het outlook profiel bij die personen eens verwijderen en een nieuwe aan (laten) maken?

[Hero of Time]

Dat had ik bij de tweede melder al gedaan. Nieuw Outlook profiel gemaakt (naast de bestaande, dat wel) gaf geen verbetering. Bij deze gebruiker werd Outlook ook onwerkbaar, want het bleef maar komen met de melding dat de agenda niet beschikbaar was. Klikte je de melding weg en wilde je een menu openen, had je pech, want een paar seconden later stond die er weer.

[The Eagle]

D_Jeff schreef op dinsdag 15 september 2020 @ 12:06:
De case & info:
Recentelijk zijn er door mijn opdrachtgever 100 Dell desktops bestelt. Deze moeten in Intune (en daarmee in AzureAD) komen te zitten/hangen/******.

Hoewel de "Device based enrolment" nog de status preview heeft, zijn we overtuigd dat het prima werkt. (= getest met 12 surfaces)

1 van de voorwaarden om Device based te kunnen gebruiken, is dat er een Hardware / System ID in Intune staat. Helaas is het verzoek om een Intune CSV bij Dell Sale net te laat aangekomen.

De vraag: Is een handige manier om deze 100 machines snel in Intune/AzureAD te krijgen? (Zonder deze 1 voor 1 af te moeten met het befaamde "Get-WindowsAutopilotinfo" script)
Dank!

Zijn die dingen al geleverd? Zo nee, accountmanager bellen en cancel die order. Schiet meteen een nieuwe in, maar dan met die csv er op. Dat is hoe die processen werken.
En als die accountmanager begint te stuiteren: prima, we gaan tegen jaareinde en jij moet blij zijn met alles wat je nu verkoopt gezien vorona etc. Dus werk er maar eens voor.

[lolgast]

@Hero of Time Het is lang geleden dat ik O365 heb beheerd, maar ik heb dit probleem ooit gehad en dat werd toen veroorzaakt door een foute/oude server URL ergens in het register. Is vast wat over te vinden op het internet als je die sleutelwoorden combineert.

[Enforcer]

Hero of Time schreef op dinsdag 15 september 2020 @ 20:11:
Dat had ik bij de tweede melder al gedaan. Nieuw Outlook profiel gemaakt (naast de bestaande, dat wel) gaf geen verbetering. Bij deze gebruiker werd Outlook ook onwerkbaar, want het bleef maar komen met de melding dat de agenda niet beschikbaar was. Klikte je de melding weg en wilde je een menu openen, had je pech, want een paar seconden later stond die er weer.

Kan het zijn dat auto-mapping een (gedeelde) agenda of mailbox probeert te openen die jij (of 1 van de andere beheerders) heeft hernoemd danwel verwijderd? Ook al gooi je het outlook profiel weg dan nog zal auto-mapping ervoor zorgen dat deze onherroepelijk erbij komt bij het connecten naar de Exchange omgeving. Dat wil nog wel eens issues geven voornamelijk bij het hernoemen van mailboxen/agenda's is mijn ervaring.

[ Voor 6% gewijzigd door Enforcer op 15-09-2020 20:36 ]

[asing]

Hero of Time schreef op dinsdag 15 september 2020 @ 17:56:
Als Outlook constant verbinding probeert te maken, maar mislukt om onbekende reden (volgens de logs en meldingen die de gebruiker krijgt), wat zou er dan aan de hand kunnen zijn?

Ik heb nu 3 gebruikers op onze RDS (2012R2, Office/Outlook 2016) die hier last van hebben. Eentje stuurde ik vanochtend naar een andere server en toen werkte 't weer, maar bij een van de andere twee die gisteren ook al issues had mocht dat trucje niet baten.

Nu heb ik vorige week de AAD sync naar O365 uitgeschakeld (in AADsync zelf, kon 't online in AAD zelf niet vinden waar velen naar verwijzen, de portal is verandert) en afgelopen weekend gebruikers naar een ander interne AD verhuisd, maar ik zou verwachten dat dat niet de oorzaak mag zijn. Ook omdat het bij de laatste van de gebruikers op z'n laptop wel prima werkt met W10 en Office 2016. De AADsync staat nog uit, ivm een laatste paar gebruikers die over moeten.

Wat zegt de connection manager? Balkje bij klok open klikken, ctrl indrukken, rechter muis op Outlook icoon en dan connections.

[Hero of Time]

@lolgast, maar waarom werkt het bij een gebruiker dan opeens wel als die op een andere server komt? En bij de andere gebruiker die naar diezelfde, 'werkende' server gaat niet?

@Enforcer, er is tussen twee weken geleden en nu in principe niets verandert aan de online omgeving. Alleen dus die user sync uit sinds woensdag en de AD verandering. Ik dacht eerder nog aan het feit dat de gebruiker in het oude AD is uitgeschakeld en de PHS SSO methode naar de verkeerde user kijkt, maar dat klopt ook niet omdat het juist via AAD authenticeert. Dan zou het mogelijk nog de kerberos zaken kunnen zijn, maar dan kom ik weer bij het punt bovenaan deze post: ene gebruiker doet 't wel, andere niet op dezelfde machine.

@asing, morgen eens kijken. Een van de gebruikers is morgen op kantoor.

[asing]

@Hero of Time tipje : In Azure AD kan je in de lijst met gebruikers de mislukte login pogingen zien. Dat kost je 2 minuten om te kijken, en het sluit meteen uit dat wachtwoorden niet meer kloppen. Kan de gebruiker met problemen wel inloggen in portal.office.com en daar naar zijn/haar mail?

Verder moet je niet roepen dat er niks is gewijzigd aan de Microsoft kant. Ten eerste : dat weten we niet , en ten tweede, er wordt constant aan gesleuteld. Dus er veranderd altijd wel wat. We hebben met zijn allen een abonnement op de speeltuin van de Microsoft Devvers.

[lolgast]

Hero of Time schreef op dinsdag 15 september 2020 @ 22:58:
@lolgast, maar waarom werkt het bij een gebruiker dan opeens wel als die op een andere server komt? En bij de andere gebruiker die naar diezelfde, 'werkende' server gaat niet?

...

Omdat het in de HKCU staat? SBC ontslaat je niet van individuele usersettings

[Hero of Time]

asing schreef op dinsdag 15 september 2020 @ 23:46:
@Hero of Time tipje : In Azure AD kan je in de lijst met gebruikers de mislukte login pogingen zien. Dat kost je 2 minuten om te kijken, en het sluit meteen uit dat wachtwoorden niet meer kloppen. Kan de gebruiker met problemen wel inloggen in portal.office.com en daar naar zijn/haar mail?

Niks geen meldingen over failed logon, alleen maar succes meldingen. En ook geen honderden entries in korte tijd vanwege de vele pogingen om verbinding te maken.

Je eerdere tip over de connection status had ik nog even naar gekeken. Bij eentje gekeken en daar zie ik wel dat het verbinding heeft, om direct weer weg te vallen en opnieuw proberen te verbinden. Bij maar 1 van de verbindingen, de anderen, voor agenda, contacten e.d. denk ik, blijven gewoon op verbonden staan.

Verder moet je niet roepen dat er niks is gewijzigd aan de Microsoft kant. Ten eerste : dat weten we niet , en ten tweede, er wordt constant aan gesleuteld. Dus er veranderd altijd wel wat. We hebben met zijn allen een abonnement op de speeltuin van de Microsoft Devvers.

Klopt, maar ik acht de kans groter dat het een lokaal ding is door mijn werkzaamheden, dan het geknutsel van de cloud devvers.

lolgast schreef op dinsdag 15 september 2020 @ 23:51:
[...]

Omdat het in de HKCU staat? SBC ontslaat je niet van individuele usersettings

Wat heeft user settings te maken met het feit dat een gebruiker op server1 gezeik heeft en na opnieuw inloggen op server2 komt en alles werkt? Dat is dan toch niet logisch? Zeker als de andere gebruiker met gedoe naar diezelfde server2 gaat en de problemen daar blijven bestaan.


Morgen is ze ook weer op kantoor, ik ga dan kijken of een nieuwe UPD voor haar wat oplost. Zal ik haar eerst even helpen met de bookmarks exporteren, dat is wel zo fijn. Wachtwoorden staan toch al veilig.

[Satangel]

Iemand ervaring met 3D PDF's die niet consistent werken?

Mijn gebruikers hebben Adobe 20.012.20043 versie en kunnen éénmalig een 3D PDF openen.
De volgende keer dat ze dit proberen lukt dit niet meer, enkel nadat ze in AppData een map hernoemen lukt dit opnieuw éénmalig. Is een probleem dat al heel lang aansleept

Vreemde is dat het bij sommige gebruikers wel consistent lijkt te werken, bij andere dan niet. Ik zie het verschil niet

[Rossi]

Case:
Wij beheren als MSP ongeveer 50 Microsoft365-tenants. Hierdoor is het ongeveer ondoenlijk om in elke Tenants named admin-accounts aan te maken, laat staan te beheren/verwijderen bij personeelswisselingen.
De meeste beheerzaken doen we via het Partner-portal, maar helaas werkt lang niet alles via dat Portal. Hierdoor moeten we dus toch af en toe inloggen met een Global Admin.
Deze Global Admins willen we uiteraard beschermen via een veilig wachtwoord maar ook via MFA. Maar hoe deel je deze MFA-accounts:

• Iedereen de QR-code laten scannen zodat iedereen op zijn eigen telefoon MFA-codes kan opvragen
• 1 MFA telefoon (op kantoor ofzo) waar dan iemand moet zijn om de code door te geven (lijkt me niet heel handig)
• PIM - helaas bij een groot deel van de klanten geen optie omdat men geen E3/E5 heeft
• Een app als Authy gebruiken welke je ook op je desktop kan installeren voor extra gemak

Ik ben heel benieuwd of er andere mensen zijn die bij MSPs werken en hoe ze met deze uitdaging om gaan.

[Hero of Time]

Het probleem wat een paar van m'n gebruikers hadden mbt Outlook is opgelost. En het zat op een plek waar je never nooit niet aan zou hebben gedacht.

Omdat Google Chrome door een stel incompetente beunhazen wordt geschreven, gaat het janken als de TEMP map niet naar een schijfletter is te herleiden. We maken gebruik van profile disks op onze RDS, dus %TEMP% is feitelijk een mount point op een andere schijf. Om dit op te lossen heb ik voor de RDS omgeving een GPO met loopback processing die de TEMP en TMP variabelen zet op een locatie op de C: schijf. En tegelijk de map aanmaakt.

Dit werkte dus prima. Maar om een of andere reden was voor een paar gebruikers opeens die map weg. En voor nog vreemdere reden kon die ook niet gemaakt worden, terwijl er aan de NTFS rechten eigenlijk niets verandert was.

Hoewel ik nu bedenk dat er wel doodleuk 'Domain Users' als groep stond, ik mij nu niet kan herinneren van welk domein deze was.... Dat zou zomaar het oude kunnen zijn geweest. Naja, er staat nu 'everyone' op en hoewel je de map zelf in kan, kan je niet in de temp van een andere gebruiker.

[GrasshopperNL]

Rossi schreef op vrijdag 18 september 2020 @ 16:48:
Case:
Wij beheren als MSP ongeveer 50 Microsoft365-tenants. Hierdoor is het ongeveer ondoenlijk om in elke Tenants named admin-accounts aan te maken, laat staan te beheren/verwijderen bij personeelswisselingen.
De meeste beheerzaken doen we via het Partner-portal, maar helaas werkt lang niet alles via dat Portal. Hierdoor moeten we dus toch af en toe inloggen met een Global Admin.
Deze Global Admins willen we uiteraard beschermen via een veilig wachtwoord maar ook via MFA. Maar hoe deel je deze MFA-accounts:

• Iedereen de QR-code laten scannen zodat iedereen op zijn eigen telefoon MFA-codes kan opvragen
• 1 MFA telefoon (op kantoor ofzo) waar dan iemand moet zijn om de code door te geven (lijkt me niet heel handig)
• PIM - helaas bij een groot deel van de klanten geen optie omdat men geen E3/E5 heeft
• Een app als Authy gebruiken welke je ook op je desktop kan installeren voor extra gemak

Ik ben heel benieuwd of er andere mensen zijn die bij MSPs werken en hoe ze met deze uitdaging om gaan.

Laatst heb ik bij ons SMS verificatie ingericht voor alle tenants, en automatisch het bericht in Teams laten posten.
Als een medewerker uit dienst gaat heeft die direct geen toegang meer tot de verificatie sms.

[Renegade666]

@GrasshopperNL
Wat heb je daar voor gebruikt? Lijkt ook wel handig voor ons.

[Hero of Time]

Kan mij zomaar voorstellen dat er iets als een Android telefoon met Tasker gebruikt kan worden. En anders een SMS modem dat ook berichten kan ontvangen en als actie daarop een script oid aftrapt om dat bericht in Teams te gooien.

[GrasshopperNL]

Renegade666 schreef op vrijdag 18 september 2020 @ 23:13:
@GrasshopperNL
Wat heb je daar voor gebruikt? Lijkt ook wel handig voor ons.

Messagebird, PowerAutomate en Teams.
Geen lokaal toestel.

[Turdie]

Rossi schreef op vrijdag 18 september 2020 @ 16:48:
Case:
Wij beheren als MSP ongeveer 50 Microsoft365-tenants. Hierdoor is het ongeveer ondoenlijk om in elke Tenants named admin-accounts aan te maken, laat staan te beheren/verwijderen bij personeelswisselingen.
De meeste beheerzaken doen we via het Partner-portal, maar helaas werkt lang niet alles via dat Portal. Hierdoor moeten we dus toch af en toe inloggen met een Global Admin.
Deze Global Admins willen we uiteraard beschermen via een veilig wachtwoord maar ook via MFA. Maar hoe deel je deze MFA-accounts:

• Iedereen de QR-code laten scannen zodat iedereen op zijn eigen telefoon MFA-codes kan opvragen
• 1 MFA telefoon (op kantoor ofzo) waar dan iemand moet zijn om de code door te geven (lijkt me niet heel handig)
• PIM - helaas bij een groot deel van de klanten geen optie omdat men geen E3/E5 heeft
• Een app als Authy gebruiken welke je ook op je desktop kan installeren voor extra gemak

Ik ben heel benieuwd of er andere mensen zijn die bij MSPs werken en hoe ze met deze uitdaging om gaan.

Inmiddels zijn er in AAD heel veel RBAC rollen, dus Global Admin heb je bijna nergens meer nodig, je zou kunnen kijken naar welke taken je doet binnen die tenants of daar een een andere rol bij past.

Ik zou gewoon wat named accounts aanmaken (zonder Office 365 licentie) en die aan de admin rol toevoegen en die protecten met MFA. Algemene admin accounts is sowieso not-done tegenwoordig, iedere auditor zal daar over gaan vallen, zeker voor Global Admin. Mocht je een klant hebt die aan strenge governance richtlijnen moet doen en access reviews moet doen dan zul je helemaal in de problemen komen.

PIM zou ook een optie kunnen zijn, maar dan moeten je klanten P2 licenties aanschaffen, wellicht kun je ze daardoor bewegen. Het gaat inmiddels om hun eigen veiligheid en beschermen van hun eigen omgeving. Je zou het bij die klanten die het wel hebben kunnen inregelen en de rest een traject in gang zetten.

[ Voor 35% gewijzigd door Turdie op 19-09-2020 16:42 ]

[FastFred]

Vorige week een ESX host uitgevallen, inmiddels gefixed, maar nu is de VM verdeling in de war. Ben nu aan het stoeien met affinity rules (niet door mij ingericht), want ik krijg sommige VM's niet gemoved naar de gewenste hosts.

Er is bijvoorbeeld een regel dat XA01, 02 en 11 op ESX1 moeten draaien. 1 en 2 krijg ik prima op ESX1, maar bij 11 krijg ik de melding dat dat niet mag want "would violate a virtual machine - host affinity rule" Terwijl 11 in geen enkele andere rule voor komt.

Nu heb ik geen VMware certificeringen en heb ik nog nooit met deze rules gewerkt dus ben eens aan het Googlen geslagen en als test een group (Seperate Virtual Machines) aangemaakt waarin 2 servers zitten die niet op dezelfde host mogen draaien. Maar als ik dan server1 wil migreren naar de host waar server2 draait dan is dat geen probleem...

[ Voor 3% gewijzigd door FastFred op 21-09-2020 15:37 ]

[Verwijderd]

Rossi schreef op vrijdag 18 september 2020 @ 16:48:
Case:
Wij beheren als MSP ongeveer 50 Microsoft365-tenants. Hierdoor is het ongeveer ondoenlijk om in elke Tenants named admin-accounts aan te maken, laat staan te beheren/verwijderen bij personeelswisselingen.
De meeste beheerzaken doen we via het Partner-portal, maar helaas werkt lang niet alles via dat Portal. Hierdoor moeten we dus toch af en toe inloggen met een Global Admin.
Deze Global Admins willen we uiteraard beschermen via een veilig wachtwoord maar ook via MFA. Maar hoe deel je deze MFA-accounts:

• Iedereen de QR-code laten scannen zodat iedereen op zijn eigen telefoon MFA-codes kan opvragen
• 1 MFA telefoon (op kantoor ofzo) waar dan iemand moet zijn om de code door te geven (lijkt me niet heel handig)
• PIM - helaas bij een groot deel van de klanten geen optie omdat men geen E3/E5 heeft
• Een app als Authy gebruiken welke je ook op je desktop kan installeren voor extra gemak

Ik ben heel benieuwd of er andere mensen zijn die bij MSPs werken en hoe ze met deze uitdaging om gaan.

MFA naar een vast telefoonnummer en de techische medewerkers in de wachtrij van dat telefoonnummer stoppen.

[Turdie]

FastFred schreef op maandag 21 september 2020 @ 15:15:
Vorige week een ESX host uitgevallen, inmiddels gefixed, maar nu is de VM verdeling in de war. Ben nu aan het stoeien met affinity rules (niet door mij ingericht), want ik krijg sommige VM's niet gemoved naar de gewenste hosts.

Er is bijvoorbeeld een regel dat XA01, 02 en 11 op ESX1 moeten draaien. 1 en 2 krijg ik prima op ESX1, maar bij 11 krijg ik de melding dat dat niet mag want "would violate a virtual machine - host affinity rule" Terwijl 11 in geen enkele andere rule voor komt.

Nu heb ik geen VMware certificeringen en heb ik nog nooit met deze rules gewerkt dus ben eens aan het Googlen geslagen en als test een group (Seperate Virtual Machines) aangemaakt waarin 2 servers zitten die niet op dezelfde host mogen draaien. Maar als ik dan server1 wil migreren naar de host waar server2 draait dan is dat geen probleem...

Dat zou DRS toch zelf recht moeten trekken? Ik snap niet helemaal waarom je VM's per host gaat verdelen. Je zou moeten bekijken per host, zoveel capaciteit hebben ze, zoveel mogen ze hebben (vaak -25%), en dat dan goed instellen dat doet DRS de rest voor je. Dat is juist het concept van virtualisatie een VM kan op iedere host draaien.....

[ Voor 12% gewijzigd door Turdie op 21-09-2020 16:08 ]

[FastFred]

@Turdie dat staat bij ons uit, anders worden er de hele tijd VM's heen en weer gegooid tussen hosts omdat de load nog wel eens wisselt. En dat heen en weer gooien geeft bij de gebruiker weer vertraging oplevert.

Maar het is al opgelost, XA11 stond nog ergens in een groepje verstopt en ik snapte nog niet goed waar ik mee bezig was

Ik snap de inrichting nu ook wat beter. Als ESX4 uitvalt, gaan alle vm's die daar draaiden naar ESX3 en andersom. Als ESX2 uitvalt, gaat alles naar ESX1 en andersom.

[ Voor 33% gewijzigd door FastFred op 21-09-2020 16:18 ]

[Oogje]

Turdie schreef op maandag 21 september 2020 @ 16:04:
[...]


Dat zou DRS toch zelf recht moeten trekken? Ik snap niet helemaal waarom je VM's per host gaat verdelen. Je zou moeten bekijken per host, zoveel capaciteit hebben ze, zoveel mogen ze hebben (vaak -25%), en dat dan goed instellen dat doet DRS de rest voor je. Dat is juist het concept van virtualisatie een VM kan op iedere host draaien.....

Er zijn genoeg redenen om te werken met hostgroups (bv HA of licenties).

[Tylen]

Turdie schreef op maandag 21 september 2020 @ 16:04:
[...]


Dat zou DRS toch zelf recht moeten trekken? Ik snap niet helemaal waarom je VM's per host gaat verdelen. Je zou moeten bekijken per host, zoveel capaciteit hebben ze, zoveel mogen ze hebben (vaak -25%), en dat dan goed instellen dat doet DRS de rest voor je. Dat is juist het concept van virtualisatie een VM kan op iedere host draaien.....

DRS voor XenApp servers (Assuming XA = XenApp) is niet according best practices

[nielsn]

Ik kom er nu achter dat de view-settings van de kalender in Outlook niet worden opgeslagen. Bij een herstart van Outlook moet ik dus steeds de agenda's weer selecteren en in de overlay modus knallen.

Helaas is dit dus niet alleen bij mij, maar bij meerdere gebruikers.

outlook.exe /resetnavpane en outlook.exe /cleanviews boden niet de oplossing. Heeft iemand dit probleem al eens getackeld?

[FastFred]

Tylen schreef op maandag 21 september 2020 @ 16:23:
[...]


DRS voor XenApp servers (Assuming XA = XenApp) is niet according best practices

XA = inderdaad XenApp servers in dit geval ja. Maar DRS staat globaal uit, niet alleen voor de XA's als uitzondering

[Turdie]

nielsn schreef op maandag 21 september 2020 @ 16:30:
Ik kom er nu achter dat de view-settings van de kalender in Outlook niet worden opgeslagen. Bij een herstart van Outlook moet ik dus steeds de agenda's weer selecteren en in de overlay modus knallen.

Helaas is dit dus niet alleen bij mij, maar bij meerdere gebruikers.

outlook.exe /resetnavpane en outlook.exe /cleanviews boden niet de oplossing. Heeft iemand dit probleem al eens getackeld?

Support ticket inschieten bij Microsoft, maar hou er rekening mee dat dit probleem al jaren voorkomt.

Ik heb het wel is meegemaakt bij een persoon en toen ik de OST gecontroleerd en gerepareerd met zo'n tool in de Office folder(SCANPST.exe), maar als jij het bij meerdere gebruikers ziet is het waarschijnijk wat anders

[ Voor 14% gewijzigd door Turdie op 21-09-2020 16:59 ]

[Oogje]

Turdie schreef op maandag 21 september 2020 @ 16:55:
[...]


Support ticket inschieten bij Microsoft, maar hou er rekening mee dat dit probleem al jaren voorkomt.

Ik heb het wel is meegemaakt bij een persoon en toen ik de OST gecontroleerd en gerepareerd met zo'n tool in de Office folder(SCANPST.exe), maar als jij het bij meerdere gebruikers ziet is het waarschijnijk wat anders

Misschien ben ik er te lang uit, maar een OST gooi je toch gewoon weg en laat je opnieuw aanmaken? Is toch niks meer dan een offline copy van de mailbox op de server?

[Turdie]

Oogje schreef op maandag 21 september 2020 @ 17:27:
[...]

Misschien ben ik er te lang uit, maar een OST gooi je toch gewoon weg en laat je opnieuw aanmaken? Is toch niks meer dan een offline copy van de mailbox op de server?

Gebruiker moet dan lang wachten om de OST opnieuw op te bouwen, vooral bij grote mailboxen. Omdat te vermijden raad ik altijd SCANPST aan.

[ Voor 6% gewijzigd door Turdie op 21-09-2020 17:56 ]

[asing]

Turdie schreef op maandag 21 september 2020 @ 16:04:
[...]


Dat zou DRS toch zelf recht moeten trekken? Ik snap niet helemaal waarom je VM's per host gaat verdelen. Je zou moeten bekijken per host, zoveel capaciteit hebben ze, zoveel mogen ze hebben (vaak -25%), en dat dan goed instellen dat doet DRS de rest voor je. Dat is juist het concept van virtualisatie een VM kan op iedere host draaien.....

Er zijn voldoende redenen te vinden om affinity danwel anti affinity rules te gebruiken. Stel je hebt 2 virtuele DCs. Dan is het handig als die 2 niet bij elkaar staan . Heeft je host een probleem, dan ben je meteen je 2 DCs kwijt . Ook iets grappigs is MS SQL server, die MAG je wel vmotionen, maar iedere hosts in het cluster moet dan gelicenseerd zijn. Je kan ermee weg komen als de VM met SQL niet binnen 90 dagen van host wisselt.

Als laatste heb je altijd wel een performance hongerige afdeling die het voor elkaar krijgt om hun eigen host in het rek te schuiven. Dan is het handig om hun VMs dan ook fijn daarop te zetten.

@FastFred : volgende keer mag je wel even een PM sturen. Het is niet handig om zonder kennis in je vSphere omgeving te klikken.

[FastFred]

@asing Nou ja dat is dus ook zoiets raars. Er is uiteraard een anti-affinity rule voor beide DC's, idem voor de Citrix Delivery Controllers, Citrix Provisioning en Citrix Gateway servers. Maar ik kan DC02 zonder problemen handmatig verkassen naar de host waar DC01 staat...

Volgens mij zit er nog ergens een conflict. Morgen maar 's verder in duiken. De helpdesk is redelijk rustig momenteel, de stagiaire doet het lang niet slecht, dus heb ik mooi tijd om hier in te duiken en dingen uit te zoeken, heerlijk

[ Voor 5% gewijzigd door FastFred op 21-09-2020 19:22 ]

[Hero of Time]

Dat 'probleem' heb ik dus ook. We hebben ESXi Standard, dus geen DRS. Maar m'n regel dat AD01 en AD02 niet bij elkaar mogen wordt vrolijk genegeerd als ik een vMotion doe van een van de twee naar de fysieke host waar de ander op staat. Ik zou verwachten dat het bij de checks gaat kijken of dat wel mag. Stel dat je 2 storage locaties hebt en je wilt een VM verhuizen, dan zal het ook gaan piepen als de doelhost niet bij de storage kan waar de VM op draait. Je zou dan toch verwachten dat het ook de regels nakijkt om te zorgen dat er geen violation optreed.

[asing]

Hero of Time schreef op maandag 21 september 2020 @ 20:00:
Dat 'probleem' heb ik dus ook. We hebben ESXi Standard, dus geen DRS. Maar m'n regel dat AD01 en AD02 niet bij elkaar mogen wordt vrolijk genegeerd als ik een vMotion doe van een van de twee naar de fysieke host waar de ander op staat. Ik zou verwachten dat het bij de checks gaat kijken of dat wel mag. Stel dat je 2 storage locaties hebt en je wilt een VM verhuizen, dan zal het ook gaan piepen als de doelhost niet bij de storage kan waar de VM op draait. Je zou dan toch verwachten dat het ook de regels nakijkt om te zorgen dat er geen violation optreed.

Stom voorbeeldje : als Server 1 niet bij Server 2 op dezelfde host mag, en doet toch een vmotion van Server 1 naar de host van Server 2, danzal DRS ingrijpen en Server 2 van die host weghalen en naar een andere host zetten.

Je krijgt alleen een melding als je zegt dat Server 1 niet bij Server 2 mag. en dat Server 2 op Host 2 *moet* draaien. Dan is er namelijk geen uitweg meer .

https://4sysops.com/archi...-rules-in-vmware-vsphere/

[Hero of Time]

@asing, maar het gaat in mijn geval helemaal niet over DRS, want dat zit niet in de Standard licentie. Als ik dus met het handje een VM naar een host slinger, moet het een waarschuwing geven en weigeren te migreren, net zoals het weigert als de storage niet beschikbaar is. En niet domweg zwijgen en accepteren. Waarom heb ik anders de rules optie? Als je Enterprise moet hebben ivm DRS, bied 't dan niet aan in Standard.

[asing]

Hero of Time schreef op maandag 21 september 2020 @ 22:50:
@asing, maar het gaat in mijn geval helemaal niet over DRS, want dat zit niet in de Standard licentie. Als ik dus met het handje een VM naar een host slinger, moet het een waarschuwing geven en weigeren te migreren, net zoals het weigert als de storage niet beschikbaar is. En niet domweg zwijgen en accepteren. Waarom heb ik anders de rules optie? Als je Enterprise moet hebben ivm DRS, bied 't dan niet aan in Standard.

Je hebt een punt, zeker. Maar ik zit me nu af te vragen waarom je in hemelsnaam die afinity rules zou hebben als je licentie geen DRS heeft . Wat is het punt daarvan ? Het idee is dat dat samenwerkt met DRS.

Anyway, probeer het eens en dan kijken of vSphere daar ergens anders een melding van geeft. Ik kan begrijpen dat hij de vmotion actie toestaat, maar als hij er daarna het zwijgen toe doet is het gek.

[Hero of Time]

asing schreef op maandag 21 september 2020 @ 23:01:
[...]

Je hebt een punt, zeker. Maar ik zit me nu af te vragen waarom je in hemelsnaam die afinity rules zou hebben als je licentie geen DRS heeft . Wat is het punt daarvan ? Het idee is dat dat samenwerkt met DRS.

Daarom mijn verbazing. Geef de functie en doe er iets mee, of geef het niet als het niet in de licentie valt.

Anyway, probeer het eens en dan kijken of vSphere daar ergens anders een melding van geeft. Ik kan begrijpen dat hij de vmotion actie toestaat, maar als hij er daarna het zwijgen toe doet is het gek.

Dat heb ik dus al eens getest. M'n AD servers mochten gezellig naast elkaar staan op dezelfde fysieke host, terwijl de rule dat niet zou moeten toestaan.

[asing]

Hero of Time schreef op maandag 21 september 2020 @ 23:29:
Dat heb ik dus al eens getest. M'n AD servers mochten gezellig naast elkaar staan op dezelfde fysieke host, terwijl de rule dat niet zou moeten toestaan.

Heel vaag. Ik ga er van uit dat je de rule wel "enabled" hebt he? Niet dat je dat ergens gemist hebt en het ding niks doet.

Er is overigens (in de Enterprise versie) een scherm met DRS recommendations. Ik weet niet of dat ook in jouw Standard editie zit maar daar kan je ook even kijken.

[Hero of Time]

asing schreef op maandag 21 september 2020 @ 23:34:
[...]

Heel vaag. Ik ga er van uit dat je de rule wel "enabled" hebt he? Niet dat je dat ergens gemist hebt en het ding niks doet.

Driedubbel gecontroleerd, de regel staat aan. Zag wel opeens dat een van de twee servers uit 't lijstje was, dus die weer toegevoegd en weer getest, nog steeds was het mogelijk. Dit keer niet de migratie laten uitvoeren, want de doelhost was al aardig 'vol'.

Er is overigens (in de Enterprise versie) een scherm met DRS recommendations. Ik weet niet of dat ook in jouw Standard editie zit maar daar kan je ook even kijken.

Ik ken 'm, die met het waterpasje. Die heb ik in de vCenter 6.7 en 7.0 interface niet gezien bij ons. Maar die zal je vast pas hebben als DRS daadwerkelijk beschikbaar is in je licentie.

[pjlgt]

Hero of Time schreef op maandag 21 september 2020 @ 23:29:
[...]

Daarom mijn verbazing. Geef de functie en doe er iets mee, of geef het niet als het niet in de licentie valt.


[...]

Dat heb ik dus al eens getest. M'n AD servers mochten gezellig naast elkaar staan op dezelfde fysieke host, terwijl de rule dat niet zou moeten toestaan.

Nav jouw post hierover ook eens gekeken of er überhaupt zo’n rule was ingesteld bij ons (ja dus) en ik kon ook gewoon beide dcs op dezelfde host zetten zonder problemen of waarschuwingen. Wij hebben ook de standaard editie. Ga volgende week toch samen met onze leverancier aan de slag met migratie naar versie 7, dus zal het hem eens voorleggen.

[asing]

Het enige wat ik kan bedenken is dat als je in je cluster een vm start, de regels wel van toepassing zijn en dc1 niet naast dc2 wordt gestart. Verder lijkt mij dat het alleen effect heeft als je ook de licentie hebt.

Maar ik ben benieuwd

[Vorkie]

@Hero of Time @asing

De separate rule werkt bij starten, dus heb je 1 host, terwijl ze separaat moeten draaien krijg je een DRS error / onmogelijk om die VM te starten.

vMotion werkt nog gewoon en kunnen ze weer gezellig samen staan.

Voorbeeldje met mijn DNS servers:
Deze moeten separaat draaien, maar 1 host staat stand-by.


Dan krijg je dus een foutmelding, hou hier dus rekening mee en gebruik eerder de should run (vm to hostgroup). Mocht er dan een host uitvallen en je VM opnieuw moeten starten, dan kan die dat tenminste.

[ Voor 17% gewijzigd door Vorkie op 23-09-2020 20:50 ]

[Hero of Time]

@Vorkie, wat jij laat zien is een Enterprise ding. Bij Standard gaan VMs niet zomaar heen en weer. Een VM staat in principe 'vast' op een host. Want bij het installeren van updates moet ik handmatig de host leeg maken zodat er niets op draait voordat de remediation verder wil.

[Vorkie]

Hero of Time schreef op woensdag 23 september 2020 @ 20:54:
@Vorkie, wat jij laat zien is een Enterprise ding. Bij Standard gaan VMs niet zomaar heen en weer. Een VM staat in principe 'vast' op een host. Want bij het installeren van updates moet ik handmatig de host leeg maken zodat er niets op draait voordat de remediation verder wil.

Dit heb je dan niet?
(Werk niet zo snel op plekken zonder Enterprise dingen )

[Hero of Time]

Vorkie schreef op woensdag 23 september 2020 @ 20:56:
[...]

Dit heb je dan niet?
(Werk niet zo snel op plekken zonder Enterprise dingen )

[Afbeelding]

Daar hebben we het vorig jaar al een paar keer over gehad en zowel ik als @pjlgt ( naamgenoot ) geven hier ook aan dat we geen Enterprise hebben, maar Standard.

[asing]

Het ziet er wel lekker gelikt uit! De tijd dat verschillende onderdelen visueel niet matchten is voorbij.

Ik wordt er heel vrolijk van!

[Hero of Time]

De kleurstelling die @Vorkie gebruikt wordt ik anders niet zo vrolijk van. Lekker, een lamp in je bakkes. Gelukkig heeft VMware daar over na gedacht en bied het een donkere modus aan. Heerlijk rustig voor de ogen. Die staren al de hele dag naar het scherm. Heb nog niet iets gezien wat niet leesbaar was (iets waar ze voor waarschuwen als je het donkere thema inschakelt).

[Vorkie]

asing schreef op woensdag 23 september 2020 @ 21:15:
Het ziet er wel lekker gelikt uit! De tijd dat verschillende onderdelen visueel niet matchten is voorbij.

Ik wordt er heel vrolijk van!

Speciaal voor @Hero of Time (en de waarschuwing is bij mij weg in de laatste versie van vCenter, op vSphere 7)

[ Voor 25% gewijzigd door Vorkie op 24-09-2020 09:23 ]

[Hero of Time]

Dat ziet er toch vele malen beter en rustiger uit dan zo'n wit vlak? Als je een schijnwerper wilt, hoef je Tweakers maar te openen.

Ik heb zelf ook al vCenter 7 draaien en onze licentie viel nog net in de v7 release periode, dus ook vSphere hypervisor zouden wel met versie 7 kunnen draaien.

Over VMware gesproken, ik heb volgens een eerdere guide het certificaat voor iig de webUI verandert naar eentje van onze PKI omgeving. Maar als ik inlog en naar het overzicht ga van het cluster, staat er een alert op een certificaat ding. Maar het zegt niet waar dit voor is, alleen 'reset to green'. Daar heb ik natuurlijk niets aan, ik wil het oplossen, als het een probleem is. Waar zou ik moeten beginnen met kijken hiervoor? Op de plek waar je o.a. de root CA certificaat kan importeren zie ik niet direct iets staan over een ongeldig of verlopen certificaat.

[asing]

Hero of Time schreef op donderdag 24 september 2020 @ 20:42:
Dat ziet er toch vele malen beter en rustiger uit dan zo'n wit vlak? Als je een schijnwerper wilt, hoef je Tweakers maar te openen.

Ik heb zelf ook al vCenter 7 draaien en onze licentie viel nog net in de v7 release periode, dus ook vSphere hypervisor zouden wel met versie 7 kunnen draaien.

Je gaat duidelijk niet voor het onderhoudscontract .

Over VMware gesproken, ik heb volgens een eerdere guide het certificaat voor iig de webUI verandert naar eentje van onze PKI omgeving. Maar als ik inlog en naar het overzicht ga van het cluster, staat er een alert op een certificaat ding. Maar het zegt niet waar dit voor is, alleen 'reset to green'. Daar heb ik natuurlijk niets aan, ik wil het oplossen, als het een probleem is. Waar zou ik moeten beginnen met kijken hiervoor? Op de plek waar je o.a. de root CA certificaat kan importeren zie ik niet direct iets staan over een ongeldig of verlopen certificaat.

In mijn herinnering ging het niet zo makkelijk als wat je hier beschrijft . Ze hebben een berg verbeteringen doorgevoerd, en de handel een stuk minder complex gemaakt.

Simpel gezegd : je kan het beste de VMCA (VMware Certificate Authority) gebruiken. Die regelt onder water alle certificaten van de hele VMWare omgeving voor je. Standaard krijgt iedere web interface van vSphere namelijk een self signed certificaat. Ik weet niet welke handleiding je volgde maar ik denk dat je ergens halverwege in de boot gesprongen bent waardoor je nu waarschuwingen ziet.

https://blogs.vmware.com/...rtificate-management.html

Voor 6.7 moest je het zo doen : https://vmarena.com/repla...-adcs-signed-certificate/ Ik weet niet of dit voor 7.0 anders is.

Bottom line : vSphere werkt standaard met self signed dingen. Als je het netjes wil maken moet je het via de VMSC doen, die dan meteen alles voor je regelt.

[Hero of Time]

asing schreef op donderdag 24 september 2020 @ 22:12:
[...]

Je gaat duidelijk niet voor het onderhoudscontract .

Dat wilde ik het management niet aan doen. De initiële aanschaf was al duur genoeg. In het eerste jaar niet direct support nodig gehad en als we (of eerder, ik) een volgende versie willen die buiten de huidige voorwaarden liggen (als in, wanneer 7.1 uit komt zeg maar of we geen updates meer kunnen krijgen, danwel de vSphere licentie voor 6.7 niet meer om te zetten is naar 7.0), kunnen we altijd nog een nieuwe licentie aanschaffen. Ik ging er even vanuit dat het 'verlengen' van de licentie zo goed als net zo veel kost als een nieuwe aanschaffen. We hebben namelijk gebruik kunnen maken van de HP OEM optie, die is aanzienlijk voordeliger dan direct bij VMware een licentie afnemen.

[...]

In mijn herinnering ging het niet zo makkelijk als wat je hier beschrijft . Ze hebben een berg verbeteringen doorgevoerd, en de handel een stuk minder complex gemaakt.

Simpel gezegd : je kan het beste de VMCA (VMware Certificate Authority) gebruiken. Die regelt onder water alle certificaten van de hele VMWare omgeving voor je. Standaard krijgt iedere web interface van vSphere namelijk een self signed certificaat. Ik weet niet welke handleiding je volgde maar ik denk dat je ergens halverwege in de boot gesprongen bent waardoor je nu waarschuwingen ziet.

https://blogs.vmware.com/...rtificate-management.html

Voor 6.7 moest je het zo doen : https://vmarena.com/repla...-adcs-signed-certificate/ Ik weet niet of dit voor 7.0 anders is.

Bottom line : vSphere werkt standaard met self signed dingen. Als je het netjes wil maken moet je het via de VMSC doen, die dan meteen alles voor je regelt.

Staat mij wel bij dat ik die route heb bewandeld. Geen apart template voor vSphere vziw, ik had de webserver template gebruikt dacht ik. Het ging iig een hoop voor mij doen. De webUI is ook van m'n PKI, de andere onderdelen hebben vergelijkbare verloopdata. Maar toch ben ik er niet helemaal gerust op de melding over certificaten, vergelijkbaar als de 'high host memory usage' melding, maar dan rood ipv (donker)geel.

Waar dit artikel het over heeft: https://kb.vmware.com/s/article/68171. Kan zo gauw geen plaatje vinden.

[asing]

Je doet iets fout maar ik krijg nog geen ingeving wat precies. Dat rood is wel een serieuze melding dus dat moet je wel oplossen.

Dat aparte template moet je wel even maken, ik weet nog dat webserver alleen niet voldoende was.

[ Voor 27% gewijzigd door asing op 25-09-2020 00:03 ]

[Hero of Time]

Bij Certificate Management staat niets dat verlopen is. De eerste die zou verlopen is de machine cert, maar pas in 2022.

De rode melding is over het verlopen of bijna verlopen van een certificaat. Die melding staat er schijnbaar al sinds februari. Mogelijk toen ik dus de certificaten ging veranderen (dat heb ik niet nagekeken wanneer het cert is uitgegeven door m'n PKI). De threshold om het te tonen is 30 dagen, als er dus een certificaat is dat minder dan zoveel dagen geldig is.

Het template dat ik heb gebruikt, is een aanpassing van de standaard webserver template. Ik heb 'm een vergelijkbare naam gegeven (als webserver). Ik herinner mij wel iets van dat ik wat instellingen van het standaard template had aangepast voor vCenter.

Nu is het wel zo, dat de melding op de absolute root van vCenter staat en ik daar eigenlijk nooit kom. Als de alert nooit uit zichzelf weggaat, bijvoorbeeld omdat je het issue hebt verholpen, kan dat wel verklaren waarom ik 'm nog zie. Ik heb de melding namelijk nooit weggeklikt als 'ack' of 'reset to green'. Dat laatste zou ik wel kunnen proberen, als het nog steeds een issue is, zou het bij de eerst volgende check (die elke 5 dagen gebeurt) weer naar voren moeten komen.

[Vorkie]

Hero of Time schreef op vrijdag 25 september 2020 @ 19:40:
Bij Certificate Management staat niets dat verlopen is. De eerste die zou verlopen is de machine cert, maar pas in 2022.

De rode melding is over het verlopen of bijna verlopen van een certificaat. Die melding staat er schijnbaar al sinds februari. Mogelijk toen ik dus de certificaten ging veranderen (dat heb ik niet nagekeken wanneer het cert is uitgegeven door m'n PKI). De threshold om het te tonen is 30 dagen, als er dus een certificaat is dat minder dan zoveel dagen geldig is.

Het template dat ik heb gebruikt, is een aanpassing van de standaard webserver template. Ik heb 'm een vergelijkbare naam gegeven (als webserver). Ik herinner mij wel iets van dat ik wat instellingen van het standaard template had aangepast voor vCenter.

Nu is het wel zo, dat de melding op de absolute root van vCenter staat en ik daar eigenlijk nooit kom. Als de alert nooit uit zichzelf weggaat, bijvoorbeeld omdat je het issue hebt verholpen, kan dat wel verklaren waarom ik 'm nog zie. Ik heb de melding namelijk nooit weggeklikt als 'ack' of 'reset to green'. Dat laatste zou ik wel kunnen proberen, als het nog steeds een issue is, zou het bij de eerst volgende check (die elke 5 dagen gebeurt) weer naar voren moeten komen.

Ik zal van de week wel even een case aanmaken bij VMWare hierover, heb op 1 van de vCenters die ik beheer dit ook, maar meer uit luiheid genegeerd (want alles doet het verder, ook updaten)

[asing]

Hero of Time schreef op vrijdag 25 september 2020 @ 19:40:
Bij Certificate Management staat niets dat verlopen is. De eerste die zou verlopen is de machine cert, maar pas in 2022.

De rode melding is over het verlopen of bijna verlopen van een certificaat. Die melding staat er schijnbaar al sinds februari. Mogelijk toen ik dus de certificaten ging veranderen (dat heb ik niet nagekeken wanneer het cert is uitgegeven door m'n PKI). De threshold om het te tonen is 30 dagen, als er dus een certificaat is dat minder dan zoveel dagen geldig is.

Het template dat ik heb gebruikt, is een aanpassing van de standaard webserver template. Ik heb 'm een vergelijkbare naam gegeven (als webserver). Ik herinner mij wel iets van dat ik wat instellingen van het standaard template had aangepast voor vCenter.

Nu is het wel zo, dat de melding op de absolute root van vCenter staat en ik daar eigenlijk nooit kom. Als de alert nooit uit zichzelf weggaat, bijvoorbeeld omdat je het issue hebt verholpen, kan dat wel verklaren waarom ik 'm nog zie. Ik heb de melding namelijk nooit weggeklikt als 'ack' of 'reset to green'. Dat laatste zou ik wel kunnen proberen, als het nog steeds een issue is, zou het bij de eerst volgende check (die elke 5 dagen gebeurt) weer naar voren moeten komen.

Laten we er even van uit gaan dat je alles goed hebt gedaan maar die error staat er.

Ik heb even de link gevolgd die je eerder gaf met het CertificateStatusAlarm. Het eerste waar je kan kijken is het VPXD log. Aangezien VCenter Server volgens mij niet meer bestaat zal je op de VCenter Virtual Appliance moeten kijken (de plek waar je nooit komt dus). Dan staat hij hier : /var/log/vmware/vpxd/vpxd.log. Even greppen om te kijken of je daar iets kan vinden.

Verder kan je de error een reset to green geven. Zit de fout er nog steeds in, dan wordt hij vanzelf weer rood.

Als laatste kan ik je https://www.robware.net/rvtools/ aanbevelen voor het periodiek checken van je omgeving.

[Hero of Time]

Moet er nog wel bij zeggen dat ik de certificaten bij vCenter 6.7 heb gedaan en de melding pas zag toen ik vCenter 7.0 draaide. Want dan kom je weer in een interface terecht waar je datacenter, cluster en hosts nog niet uitgeklapt zijn.

Ik zal 'm wel eens resetten naar groen. Als ik 't niet vergeet komende week, want dat beloofd een drukke week te worden.

[asing]

Hero of Time schreef op vrijdag 25 september 2020 @ 21:31:
Moet er nog wel bij zeggen dat ik de certificaten bij vCenter 6.7 heb gedaan en de melding pas zag toen ik vCenter 7.0 draaide. Want dan kom je weer in een interface terecht waar je datacenter, cluster en hosts nog niet uitgeklapt zijn.

Ik zal 'm wel eens resetten naar groen. Als ik 't niet vergeet komende week, want dat beloofd een drukke week te worden.

Heb je de release notes gevolgd bij de upgrade? Het kan zijn dat je daar iets had moeten doen.

Verder : check dat log en je weet meer. Dat zou kaasje voor je moeten zijn

[Hero of Time]

Vziw waren de instructies meer het punt van 'mount de install iso op je systeem, voer de installatie uit en volg de instructies'. Oude 6.7 VC opgegeven en het ging aan het werk. De oude heb ik nog als VM, in het geval dat, maar tegelijk aan is wat lastig ivm zelfde IP adres.

[asing]

Hero of Time schreef op vrijdag 25 september 2020 @ 22:10:
Vziw waren de instructies meer het punt van 'mount de install iso op je systeem, voer de installatie uit en volg de instructies'. Oude 6.7 VC opgegeven en het ging aan het werk. De oude heb ik nog als VM, in het geval dat, maar tegelijk aan is wat lastig ivm zelfde IP adres.

Het ziet er inderdaad niet ingewikkeld uit. https://www.infrazxp.com/...-from-vsphere-6-7-to-7-0/

VCenter Server Virtual Appliance aanmaken, data overzetten, hosts overzetten... en hosts upgraden . Het is een hoop verbeterd, echt een hele hoop.

Je bent lekker bezig geweest!

[Hero of Time]

De hosts moeten nog, heb alleen vCenter gedaan, aangezien die als eerste moet. Ik heb de resources niet om de hosts naar 7.0 te brengen, want ik moet dan machines gaan uitschakelen.

[Vorkie]

@Hero of Time Het zojuist een SR aangemaakt bij VMware voor het "certificaat op de root error", zal, ongeacht de uitkomst, je wel op de hoogte houden.

[kraats]

Wij hadden afgelopen vrijdag de hele VDI-omgeving (met vcenter 6.7) op z'n gat liggen omdat met het verlengen van het certificaat van die machine er blijkbaar toch één certificaat (STS) niet mee veranderd werd. En daarna kun je dus niet meer inloggen op de machine.
Uiteindelijk gefikst middels https://kb.vmware.com/s/article/76719

[Hero of Time]

Zag vandaag weer een nieuwe melding in vCenter. Een gele. Een of andere vAPI service ding zou niet goed zijn. Status yellow. Online zoeken, vind je eerst iets dat over vCenter 6.0 spreekt en het in een latere update opgelost zou moeten zijn. Heb je dus niets aan, als je 7.0.0 draait.

Kom je daarna iets tegen dat iemand last heeft van een issue met 7.0.0c. Die update naar 7.0.0d en nog steeds een probleem (wat ook werd verwacht, vanwege de changelog). En hoppa, post erna linkt naar een KB artikel waarin het euvel staat omschreven: bekend probleem, mag je negeren.

Gaat wel lekker zo met VMware.

[asing]

Ik vind dat ze het netjes hebben uitgelegd en er is weinig aan de hand behalve een OCD trigger. Moet je eens in het eventlog van een willekeurige Windows Server kijken. Die staat stijf van de errors en 9 van de 10 keer is het niks of is de melding zo generiek dat je er niks mee kan.

In de basis is VMWare Linux gebaseerd dus ik zou verwachten dat je je helemaal in je element zou voelen .

[Vorkie]

@Hero of Time
SR afgehandeld, bleek een CSR achter gebleven te zijn, onderstaand wel goed uitpluizen, als je het verkeerde weggooit, tja, you get the point

log met root in op je vCenter via SSH (eerst bash aanzetten via Appliance management) en ga naar shell

Daarna (alle certificaten ophalen)
for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo STORE $i; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done

Hier zie je dan alle certificaten, bovenin, de MACHINE_CERT moet er in ieder geval maar 1 zijn.

Daarna goed kijken naar de ALIAS en kan je met onderstaand het certificaat verwijderen:

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CSR

Daarna even momentje wachten en daarna kijken of het er weer 1 is:

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text | less

Daarna kan je "RESET TO GREEN" doen.

Mogelijk heeft VMWare vast ergens een KB artikel met deze commando's, maar nu hoefde ik alleen maar achterover te hangen en te kijken wat ie aan het doen was.

[Hero of Time]

Even voor de fatsoenlijke styling:

for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo STORE $i; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CSR

Daarna even momentje wachten en daarna kijken of het er weer 1 is:

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store MACHINE_SSL_CERT --text | less

Kan ook in code-tags, maar cmd is mooier voor oneliners.

Ik ga het morgen eens bekijken. En anders komt het volgende maand wel.

[Hero of Time]

@Vorkie, vandaag gekeken. Bij de eerste, __MACHINE_CERT, had ik een cert en csr. Die laatste stond bij 'not after feb 2020', dus ik heb maar aangenomen dat dat een probleem is en die verwijdert zoals jij ook hebt gedaan. Maandag had ik met de vsphere admin de alert op groen gezet, vandaag met m'n eigen admin en de melding stond er weer. Ik ga er even vanuit dat alerts globaal zijn en niet per user.

[Renegade666]

Klein beetje hulp gezocht van beheerders die de telefonie (Hosted voiP) bij routit hebben draaien.
Ik ben op zoek naar de HIPIN 3.0 applicatie, echter routit kan deze niet meer aan mij leveren.
In 3.1 zit een bug dat telefoonboeken boven de 1000 entry's niet meer gelezen worden..

Wie kan mij helpen aan dit stukje software.

[nescafe]

@Renegade666 https://web.archive.org/w...voipit.nl/HIPIN/HIPIN.exe

[Renegade666]

nescafe schreef op woensdag 7 oktober 2020 @ 16:45:
@Renegade666 https://web.archive.org/w...voipit.nl/HIPIN/HIPIN.exe

Thank you

[FastFred]

Vaag probleem op een vestiging...

Computer verhuist van kantoor X naar kantoor Y (zelfde pand, zelfde patchkast, andere switch). Krijgt nu ineens een IP adres van de lokale firewall (die als DHCP dient voor het wifi netwerk), in plaats van onze DHCP server op het hoofdkantoor. Poortje op de switch zit untagged zoals de rest van de poorten (die wel gewoon werken). Andere poort op de switch maakt geen verschil. Switch (48 poorts) zit nagenoeg vol en alles werkt goed, behalve deze pc.

DHCP op firewall
deelt 10.0.0.1 tot .0.253 uit voor wifi vlan
deelt 192.168.230.11 tot .230.50 uit (geen idee waarvoor eerlijk gezegd)

PC krijgt 230.28 toegewezen terwijl die eigenlijk een IP uit de reeks hieronder hoort te krijgen

DHCP op DHCP server
deelt 192.168.230.101 - 230.200 uit in default vlan (domein)

[ Voor 7% gewijzigd door FastFred op 08-10-2020 14:25 ]

[nescafe]

Twee DHCP-servers in hetzelfde segment? Dan even dhcp release / renew doen om een multicast discover te forceren, net zo vaak tot je (random) bij de goede DHCP-server uitkomt

[Hero of Time]

Als je twee DHCP servers hebt en een daarvan is Windows en de ander niet, dan zou de Windows DHCP zichzelf uitschakelen. Althans, dat was vroeger zo. Geen idee of het ook nog eens rekening houd met de scope die uitgegeven wordt.

Meerdere Windows DHCP servers is prima mogelijk, maar alleen in een AD omgeving zodat de servers met elkaar kunnen communiceren. Al van wat ik heb begrepen van Windows DHCP.

Heeft die PC niet stiekem een aparte vlan tag ingesteld staan? Kan je zien in welk VLAN het apparaat hangt? Krijgt een ander systeem op diezelfde poort wel de juiste IP config?

[FastFred]

Die twee DHCP servers zijn idd wat raar, maar dat staat al jaren zo geconfigureerd (alleen de reden weet ik niet) en heeft nooit deze problemen opgeleverd

De een is inderdaad Windows, de firewall is Dell Sonicwall

En ik kan momenteel helemaal niemand op die vestiging bereiken om de Teamviewer sessie op die pc weer te starten of om ff een kabeltje te laten omprikken.

[ Voor 26% gewijzigd door FastFred op 08-10-2020 14:55 ]

[Hero of Time]

Als er maar 1 Windows DHCP server aanwezig is, dan is de tweede van de router/firewall wel logisch an sich. Mocht namelijk die Windows bak uitvallen, kan je iig nog het netwerk op zonder een vast adres te moeten invullen. Als je meerdere locaties hebt, kan dat nogal vervelend zijn om te onthouden of uitzoeken welke scope er gebruikt wordt en dan ook nog welk adres er werkelijk vrij is. Niet iedereen heeft tenslotte een document met alle IP reeksen en vaste adressen op z'n laptop staan.

[Brahiewahiewa]

FastFred schreef op donderdag 8 oktober 2020 @ 14:19:

DHCP op firewall
deelt 10.0.0.1 tot .0.253 uit voor wifi vlan
deelt 192.168.230.11 tot .230.50 uit (geen idee waarvoor eerlijk gezegd)

PC krijgt 230.28 toegewezen terwijl die eigenlijk een IP uit de reeks hieronder hoort te krijgen

DHCP op DHCP server
deelt 192.168.230.101 - 230.200 uit in default vlan (domein)

Maar is er een probleem, behalve dat jij het niet begrijpt?
Ik bedoel: kennelijk heeft iemand besloten tot deze vorm van redundantie, zonder jou daarover in te lichten
Maar voor zover ik het kan bekijken is het allemaal keurig geregeld en bijt het elkaar niet

[FastFred]

Hero of Time schreef op donderdag 8 oktober 2020 @ 15:27:
Als er maar 1 Windows DHCP server aanwezig is, dan is de tweede van de router/firewall wel logisch an sich. Mocht namelijk die Windows bak uitvallen

Uiteraard hebben wij 2 Windows DHCP servers op hoofdkantoor staan

Als je meerdere locaties hebt, kan dat nogal vervelend zijn om te onthouden of uitzoeken welke scope er gebruikt wordt en dan ook nog welk adres er werkelijk vrij is. Niet iedereen heeft tenslotte een document met alle IP reeksen en vaste adressen op z'n laptop staan.

IP overzicht hebben we gewoon hoor. Iedere vestiging zijn eigen IP range en middels IP VPN met de hoofdvestiging/serverpark verbonden. Vanwege het uitzonderlijk hoge aantal desktop pc's op deze vestiging hebben ze een eigen firewall en lokale internet ontsluiting voor die pc's. Iedere andere vestiging met misschien 1 of 2 desktop pc's heeft geen eigen firewall, alleen een router en switch, en internet ontsluiting via de IP VPN naar ons hoofdkantoor.

Brahiewahiewa schreef op donderdag 8 oktober 2020 @ 15:50:
Maar is er een probleem, behalve dat jij het niet begrijpt?
Ik bedoel: kennelijk heeft iemand besloten tot deze vorm van redundantie, zonder jou daarover in te lichten
Maar voor zover ik het kan bekijken is het allemaal keurig geregeld en bijt het elkaar niet

Er is wel degelijk een probleem. De gebruiker zit nu thuis te werken, logt in in Citrix, en vanuit daar start een RDP sessie naar z'n pc zodat ie met Solidworks werken kan. Maar die RDP verbinding lukt nu niet.

^{Ja ik weet dat dat ook kan met zo'n Citrix Desktop Agent (ofzo iets) op de pc i.p.v. via RDP, dat hebben we een tijd terug geprobeerd maar niet stabiel werkend kunnen krijgen}

[ Voor 20% gewijzigd door FastFred op 08-10-2020 16:20 ]

[FastFred]

Inmiddels opgelost, die DHCP scope in de 230.* reeks op de firewall uitgezet en pc herstart en werkt weer.

Maar hoe dat zo ineens voor problemen kan zorgen terwijl dat zeker 1 jaar zo gestaan heeft...

[ Voor 3% gewijzigd door FastFred op 08-10-2020 17:37 ]

[Brahiewahiewa]

FastFred schreef op donderdag 8 oktober 2020 @ 17:36:
Inmiddels opgelost, die DHCP scope in de 230.* reeks op de firewall uitgezet en pc herstart en werkt weer.

Maar hoe dat zo ineens voor problemen kan zorgen terwijl dat zeker 1 jaar zo gestaan heeft...

Je hebt het symptoom nu bestreden. Over de oorzaak kunnen wij niets zeggen met de beperkte info die je gegeven hebt. Dan zul je toch echt meer moeten vertellen over je VLAN's en firewalls

[Dronium]

FastFred schreef op donderdag 8 oktober 2020 @ 15:59:

Er is wel degelijk een probleem. De gebruiker zit nu thuis te werken, logt in in Citrix, en vanuit daar start een RDP sessie naar z'n pc zodat ie met Solidworks werken kan. Maar die RDP verbinding lukt nu niet.

Ik kan daar twee oorzaken voor bedenken :

1. Voor de PC is op de MS DHCP een reservering actief en de RDP snelkoppeling gaat naar dat IP adres
2. De RDP snelkoppling wijst naar de PC naam, maar als de PC zijn adres van de Sonicwall krijgt vindt er geen registratie van de PC naam in DNS plaats. Mogelijk omdat DNS niet naar een Domain Controller wijst.

[FastFred]

@Dronium

1. Er is geen reservatie op de Windows DHCP server voor deze pc
2. De RDP wordt gemaakt op computer naam
3. De DNS servers die de pc toegewezen krijgt zijn onze DHCP servers, terwijl het IP adres uitgedeeld wordt doro de sonicwall (tevens default gateway voor de vestiging).

[ Voor 6% gewijzigd door FastFred op 09-10-2020 11:10 ]

[noskill]

Hey, lees dat het over de nieuwe ESX/vCenter versie gaat. Klopt het dat de vereisten van de OS drive veranderd zijn? Ik heb alle hosts hier draaien of vanaf een interne USB disk, of een interne SD kaart. Toen ik een paar maanden geleden een nieuwe host voor ons cluster kocht, werd me aangeraden een 2 m.2 schijven in een RAID opstelling te kopen voor de VMware OS disk, "om aan de ESXi 7.0 eisen te voldoen". Heb hier niet verder naar gekeken en besloten dat we op 6.7 blijven voorlopig - heeft iemand hier al mee te maken gehad?