Het algemene Exchange 2016 topic

[pitchdown]

Verwijderd schreef op donderdag 25 oktober 2018 @ 16:42:
[...]

Heb je de mailboxen toevallig ook zelf nog gemapped? Of zijn ze via automapping ingesteld? Zo ja: even profiel opnieuw aanmaken of de mailboxen verwijderen en automapping opnieuw toevoegen.

Automatisch.
Ik heb de mailboxen niet via outlook zelf toegevoegd.

Misschien heeft het iets met dit te maken: https://www.gothamweb.com...o-Office-365-mailbox.html

Outlook wil dan volgens mij de mailbox-authenticatie in office365 doen (terwijl de mailbox on-premis staat).

Ik heb de registry key lokaal toegevoegd op mijn w10-client.
Echter nog geen resultaat.

[pitchdown]

wagenveld schreef op donderdag 25 oktober 2018 @ 13:35:
Dan zou ik Fiddler er eens bijpakken.
edit: Of heb je hier last van?
https://support.microsoft...e-registry-settings-under

ExcludeExplicitO365Endpoint (only applies to Outlook 2016 version 16.0.6741.2017 and later versions)

Bovenstaande ExcludeExplicitO365Endpoint lijkt de oplossing te zijn.
Heb nu een 32bits DWord key gedaan en het lijkt te werken.

Top en bedankt!

Was jij hier al eerder tegenaan gelopen? Het heeft nl. sowieso met office2019 te maken.

[wagenveld]

Toevallig was er van de week nog een topic over, is een vervelende!

[be3a18]

Ik heb een vraag over de transactielog bestanden. Die blijven in ons geval bestaan.

We hebben circulaire logboekregistratie uit staan. Kan ik dit online aanzetten, ik bedoel treedt het direct in werking of moet de database hiervoor plat?

Ik heb begrepen dat de transactielog bestanden ook worden verwijderd na een succesvolle back-up van de database. Wij gebruiken echter een externe applicatie waarna dit dus niet gebeurd.

Welke methode is te preferreren, circulaire registratie of via de back-up?

Verder zie ik dat de datum van de database op vorige week staat. Heeft dat weer te maken met het niet verwerken van de transactielog bestanden?

Ik zie net dat op de server (2016) de Volume Shadow Copy (VSS) gestopt is. Kan dit het een en ander verklaren?

[ Voor 8% gewijzigd door be3a18 op 09-11-2018 11:50 ]

[Onbekend]

Ik heb dit probleem de afgelopen weken ook gehad op Windows 10 met Outlook 2016 en Exchange 2016.
Alleen de ExcludeExplicitO365Endpoint was niet de volledige oplossing.
Eerst moet je in de admin center van Exchange de rechten op andere mailboxen van de betreffende gebruiker verwijderen.

Daarna lokaal jouw mailprofiel verwijderen en opnieuw een profiel aanmaken. (Tussen het verwijderen en opnieuw aanmaken moet minimaal 90 minuten tussen zitten, omdat het altijd even duurt voordat de rechten in het domein zijn doorgevoerd.)

Mocht dit niet werken, dan moet Outlook opnieuw worden geïnstalleerd (repareren lukt niet). Na het verwijderen van Office en opnieuw opstarten van de pc, moet je in het register de "Computer\HKEY_CURRENT_USER\Software\Microsoft\Office" en "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office" verwijderen en dan de pc opnieuw opstarten.

Na het opnieuw installeren van Office zou dit probleem over moeten zijn.
(Ik ben er tot deze week vele uren tijd aan kwijt geweest om het probleem op te lossen, maar was uiteindelijk gelukt. )

[ Voor 3% gewijzigd door Onbekend op 09-11-2018 12:04 ]

[Jazzy]

be3a18 schreef op vrijdag 9 november 2018 @ 11:22:
Ik heb een vraag over de transactielog bestanden. Die blijven in ons geval bestaan.

We hebben circulaire logboekregistratie uit staan. Kan ik dit online aanzetten, ik bedoel treedt het direct in werking of moet de database hiervoor plat?

Als het een database is met een enkele kopie dan moet je hem dismounten en opnieuw mounten. Als het een database is met meer dan één kopie dan is dat niet nodig en wordt circular logging direct toegepast.

Welke methode is te preferreren, circulaire registratie of via de back-up?

Voor het enige ondersteunde restoreproces haal je het databasebestand terug uit je laatste backup. Dan mis je nog alle wijzigingen tussen de laatste backup van de database en nu. Die staan in de logfiles, die je dus ook nodig hebt om de teruggezette database helemaal actueel te maken. Daarom verwijdert Exchange alle oude logfiles zodra het vaststelt dat er een supported full backup van de database gemaakt is.

Als jij op een andere manier de backup maakt en restores uitvoert dan moet je eerst zeker weten dat je de logfiles niet nodig hebt bij een restore. Zo niet, dan is circular logging een prima oplossing.

[be3a18]

Duidelijk verhaal. Nog 1 vraag, wat bedoel je met een enkele kopie?

Jazzy schreef op vrijdag 9 november 2018 @ 12:01:
[...]
Als het een database is met een enkele kopie dan moet je hem dismounten en opnieuw mounten. Als het een database is met meer dan één kopie dan is dat niet nodig en wordt circular logging direct toegepast.

[...]

Voor het enige ondersteunde restoreproces haal je het databasebestand terug uit je laatste backup. Dan mis je nog alle wijzigingen tussen de laatste backup van de database en nu. Die staan in de logfiles, die je dus ook nodig hebt om de teruggezette database helemaal actueel te maken. Daarom verwijdert Exchange alle oude logfiles zodra het vaststelt dat er een supported full backup van de database gemaakt is.

Als jij op een andere manier de backup maakt en restores uitvoert dan moet je eerst zeker weten dat je de logfiles niet nodig hebt bij een restore. Zo niet, dan is circular logging een prima oplossing.

[Jazzy]

be3a18 schreef op vrijdag 9 november 2018 @ 12:07:
Duidelijk verhaal. Nog 1 vraag, wat bedoel je met een enkele kopie?

In Exchange 2007 en nieuwer kun je een tweede kopie van je database bijhouden op een andere server, vanaf Exchange 2010 zelfs 15 extra kopieën. Als je niet weet wat ik bedoel dan heb je dit waarschijnlijk niet.

[ Voor 9% gewijzigd door Jazzy op 09-11-2018 12:09 ]

[be3a18]

Jazzy schreef op vrijdag 9 november 2018 @ 12:09:
[...]
In Exchange 2007 en nieuwer kun je een tweede kopie van je database bijhouden op een andere server, vanaf Exchange 2010 zelfs 15 extra kopieën. Als je niet weet wat ik bedoel dan heb je dit waarschijnlijk niet.

Oké, dat is bij ons niet het geval.

[Question Mark]

be3a18 schreef op vrijdag 9 november 2018 @ 11:22:
Ik heb begrepen dat de transactielog bestanden ook worden verwijderd na een succesvolle back-up van de database. Wij gebruiken echter een externe applicatie waarna dit dus niet gebeurd.

Ik zou daar wel even induiken. Als je niet via de VSS-writer je backup maakt, is je backup niet crash-consistent en is het maar afwachten of deze uberhaubt werkbaar te restoren is.

Wordt je backup wél via de VSS-writer gemaakt, dan zou Exchange zelf zijn lofgiles moeten flushen. Ergens gaat dus iets niet goed.

Wat voor backuptool gebruik je, en hoe staat je backup ingesteld? En ik zeg het alvast: een backup van de databasefile is niet de juiste manier.

[be3a18]

Question Mark schreef op vrijdag 9 november 2018 @ 12:50:
[...]

Ik zou daar wel even induiken. Als je niet via de VSS-writer je backup maakt, is je backup niet crash-consistent en is het maar afwachten of deze uberhaubt werkbaar te restoren is.

Wordt je backup wél via de VSS-writer gemaakt, dan zou Exchange zelf zijn lofgiles moeten flushen. Ergens gaat dus iets niet goed.

Wat voor backuptool gebruik je, en hoe staat je backup ingesteld? En ik zeg het alvast: een backup van de databasefile is niet de juiste manier.

We maken gebruik van Veaam. Als ik het forum op hun website hierover lees zou het wel moeten kunnen. Er moet wel een bepaalde setting aan staan waardoor Exchange weet dat er een back-up gemaakt is. Iets met back-up aware oid.

[Question Mark]

be3a18 schreef op zaterdag 10 november 2018 @ 10:35:
[...]
Iets met back-up aware oid.

Da's exact wat ik bedoel. Als die instelling niet juist staat, weet Exchange niet dat hij (succesvol) gebackupped is, en zijn logfiles kan flushen. Loop je instellingen dus even na.

[be3a18]

Question Mark schreef op zaterdag 10 november 2018 @ 10:43:
[...]

Da's exact wat ik bedoel. Als die instelling niet juist staat, weet Exchange niet dat hij (succesvol) gebackupped is, en zijn logfiles kan flushen. Loop je instellingen dus even na.

Ga ik doen.

[Vorkie]

Voor Veeam en Exchange en VSS back-up zou je dit minimaal moeten aan hebben voor je Exchange servers.

[be3a18]

Vanochtend hebben we de circulaire logboekregistratie aangezet. Vrijwel direct werd de hele map een stuk opgeschoond. Er zijn nu nog maar een paar log bestanden over.

Een andere vraag, dit betreft het verplaatsen van een mailbox van Exchange 2013 naar 2016. Het is een vrij forse, bijna 20GB.

Vanwege het gemak heb ik dit gestart via het Exchange-Beheercentrum. Keurig alle velden ingevuld en vervolgens gestart. De status daar staat nu op Synchroniseren. En bij Statistieken staat wel de start tijd maar verder niks. Ik weet dus niet hoe ver het er mee is. Ik heb nog gezocht op PS commando's in de Exchange Management Shell maar die doen het niet. De betreffende commando's staan ook niet in het overzicht als je Get-ExCommand uitvoert. Get-MoveRequest geeft geen resultaat, alleen van de mailboxen die al eerder succesvol zijn verplaatst.

Hoe kan ik nu de status van deze verhuizing opvragen? Kan ik ook een log bestand oid raadplegen?

Ik vrees dat het gemak even de overhand had; ik had het beter vanuit PS kunnen doen.

[Jazzy]

Als je de migratie start in het Exchange Amin Center dan worden de move requests gebundeld in een migrationbatch. Doe maar eens Get-ExCommand *batch* en dan zie je wel wat ik bedoel.

[be3a18]

Jazzy schreef op dinsdag 13 november 2018 @ 13:27:
Als je de migratie start in het Exchange Amin Center dan worden de move requests gebundeld in een migrationbatch. Doe maar eens Get-ExCommand *batch* en dan zie je wel wat ik bedoel.

Net uitgevoerd, geen foutmelding maar ook geen resultaat. Waar moet ik kijken?

Ik heb dit commando op de Windows 2012 Server met Exchange 2013 uitgevoerd vanuit de Exchange Management Shell (uitgevoerd als Administrator).

[Jazzy]

Ah, ik zie net dat je Get-Excommand niet meer kunt gebruiken tegenwoordig door de manier waarop de functie geschreven is. Gebruik Get-Command maar gewoon op op *batch* te zoeken en dan even door de output heenschrollen om de Exchange cmdlets te vinden.

Ik wilde je in ieder geval naar de cmdlets als Get-MigrationBatch en New-MigrationBatch verwijzen.

[be3a18]

Jazzy schreef op dinsdag 13 november 2018 @ 13:57:
Ah, ik zie net dat je Get-Excommand niet meer kunt gebruiken tegenwoordig door de manier waarop de functie geschreven is. Gebruik Get-Command maar gewoon op op *batch* te zoeken en dan even door de output heenschrollen om de Exchange cmdlets te vinden.

Ik wilde je in ieder geval naar de cmdlets als Get-MigrationBatch en New-MigrationBatch verwijzen.

Ik kom in het hele overzicht van Get-Command niks tegen van *batch* (of ik kijk niet goed).
Beide cmdlets doen het niet (Foutmelding niet gevonden). Is er nog verschil op welke Server de commando's uitgevoerd worden?

[ Voor 7% gewijzigd door be3a18 op 13-11-2018 16:59 ]

[Question Mark]

be3a18 schreef op dinsdag 13 november 2018 @ 13:23:
Vanochtend hebben we de circulaire logboekregistratie aangezet. Vrijwel direct werd de hele map een stuk opgeschoond. Er zijn nu nog maar een paar log bestanden over.

Controleer je nog je backup even. Er ging iets niet goed in het backupmechanisme waardoor Exchange je logfiles niet flusht. Het zou een beetje lullig zijn als je deze issue niet fixed, en er nu vanuit gaat dat je backup goed is.

[Turdie]

be3a18 schreef op dinsdag 13 november 2018 @ 16:38:
[...]


Ik kom in het hele overzicht van Get-Command niks tegen van *batch* (of ik kijk niet goed).
Beide cmdlets doen het niet (Foutmelding niet gevonden). Is er nog verschil op welke Server de commando's uitgevoerd worden?

Ja de Exchange PowerShell modules(onderdeel van de Exchange Management Tools tijdens de installatie van Exchange) moeten geinstalleerd zijn. Probeer dit eens:

PowerShell:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

Je kunt gemakkelijker de Powershell cmdlets achterhalen met "batch" erin door dit te doen

PowerShell:

 Get-Command | Select-String -Pattern batch

[ Voor 18% gewijzigd door Turdie op 13-11-2018 19:41 ]

[be3a18]

shadowman12 schreef op dinsdag 13 november 2018 @ 19:25:
[...]


Ja de Exchange PowerShell modules(onderdeel van de Exchange Management Tools tijdens de installatie van Exchange) moeten geinstalleerd zijn. Probeer dit eens:

PowerShell:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

Je kunt gemakkelijker de Powershell cmdlets achterhalen met "batch" erin door dit te doen

PowerShell:

 Get-Command | Select-String -Pattern batch

Ik ga met beide morgen aan de slag. Back-up en bovenstaande. Bedankt.

[be3a18]

We zijn nu 24 uur verder; ik heb de migratiebatch gecontroleerd die was opgestart. Zo te zien is er helemaal niks gebeurd. De statistieken zijn niet bijgewerkt (helemaal geen informatie, alleen maar wanneer de batch gestart was).

[Update]
Ik heb de migratiebatch in het Exchange-Beheercentrum daar gestopt en verwijderd.

Ik heb nu een New-MoveRequest gestart via PS (de Exchange Management Shell). Bij de status staat nu In Progress. Alleen helaas niet het percentage.

[ Voor 54% gewijzigd door be3a18 op 14-11-2018 10:01 ]

[be3a18]

De mailbox is succesvol overgezet.

Met Get-MoveRequestStatistics -Identity 'naam' | fl kon ik de operatie volgen. In eerste instantie mislukte die omdat ik niet de optie -BadItemLimit <getal> -AcceptLargeDataLoss had opgegeven en er (achteraf) 1 fout mailtje tussen zat. Daarna weer gedraaid met wel bovengenoemde opties en dat was de oplossing.

Nu de volgende uitdaging; de openbare mappen, in totaal zo'n 40GB. Met helaas behoorlijk wat subfolders. Eén folder naar de andere database verplaatsen is niet zo'n probleem. Enige honderden handmatig doen wel. Ik zie dat er een voorgebakken script is (Move-PublicFolderBranch) maar verplaatst dat de berichten naar de andere database?

[be3a18]

Nog even terugkomend op vorige comment, verplaatsen openbare mappen is gelukt. Alles draait nu op de Echange 2016 server.

Ik ga nu ook over de back-up van de servers, ga ik gelijk naar de settings daarvan kijken.

Nu een ander probleem, de Default Global Address List.

Vorige week een nieuwe gebruiker aangemaakt in Active Directory en ook een e-mailadres in Exchange. Probleem is dat ik haar niet in de Default Global Address List krijg in Outlook. Via het Exchange Beheer centrum krijg ik haar wel in de lijst te zien.

Ik ben er inmiddels achter dat als ik de cache modus in Outlook uitschakel ze wel in de Default Global Address List verschijnt. Zet ik de cache modus weer aan dan is ze weer weg.

Als ik probeer het adresboek te downloaden krijg ik de fout (0x80190194). Ik heb de rechten gecontroleerd op Exchange 2016 Server in oab map op het web.config bestand en die staan goed (Read rechten voor Authenticated Users). Sterker nog, als beheerder heb ik alle rechten op dat bestand maar ik kan het adresboek ook niet downloaden.

De combinatie is een Exhange 2016 standard server met Outlook 2016.

Ik heb onderstaande nog gevonden maar dat vind ik een beetje link.

http://www.it.ltsoy.com/e...ate-oab-error-0x80190194/

[ Voor 6% gewijzigd door be3a18 op 30-11-2018 16:05 ]

[wagenveld]

Maar heb je daar CNF waardes staan of niet? En staan je nieuwe databases op de goede OAB?
https://practical365.com/...dress-book-configuration/

[be3a18]

wagenveld schreef op vrijdag 30 november 2018 @ 16:11:
Maar heb je daar CNF waardes staan of niet? En staan je nieuwe databases op de goede OAB?
https://practical365.com/...dress-book-configuration/

Ik heb het nog niet nagekeken omdat ik het nogal link vond. Maar ik zal nog eens kijken. Bij de link die je vermeld, wordt alles dan aan de database gekoppeld? Op zich aantrekkelijk maar dan draait alles op de Exchange server neem ik aan?

[be3a18]

Onderstaande kwam ik tegen over bovengenoemd probleem.

https://social.technet.mi...s-out-on?forum=Exch2016GD

Om kort samen te vatten, dit betreft een update die Microsoft in september heeft uitgebracht.

Dit zou wel eens de oorzaak van het probleem kunnen zijn.

[ Voor 13% gewijzigd door be3a18 op 05-12-2018 10:02 ]

[be3a18]

Ik ben nog steeds aan het proberen de oude Exchange 2013 database te verwijderen zodat we van die server af kunnen. Alles is inmiddels verplaats naar de nieuwe database. Op 1 mailbox na blijkt nu.

Als ik het commando Remove-MailboxDatabase combineer met de -Verbose parameter draai blijkt er nog 1 mailbox in de database te zitten.

Remove-MailboxDatabase : Mailbox with DistinguishedName CN=SystemMailbox{1f05a927-192f-4044-b53a-64ecc9780e32},CN=Users,DC=xxxxx,DC=xxx,DC=local" is still present in this database.

Het blijkt nu dat dit het Microsoft Exchange Approval Assistant account is (opgezocht in Active Directory).

Hoe krijg ik deze mailbox uit de oude database? Of, hoe laat ik dit account verwijzen naar de nieuwe database?

Ik zie nu in ADSI dat de waarde homeMDB bij dit account nog verwijst naar de oude database.

Ik ben erachter gekomen dat ik te weinig rechten had op het gebeuren, dat heb ik gecorrigeerd. In totaal zijn er nog 7 hidden mailboxen (tbv Arbitration en Monitoring). Die ben ik nu aan het verplaatsen.

Zojuist onderstaande uitgevoerd:

[PS] C:\Windows\system32>Remove-MailboxDatabase "Mailbox Database 0118869248" -Verbose
VERBOSE: [08:48:50.673 GMT] Remove-MailboxDatabase : Runspace context: Executing user:
xxxxx.xxx.local/Personeel/xxxxx, Executing user organization: , Current organization: , RBAC-enabled:
Enabled.
VERBOSE: [08:48:50.673 GMT] Remove-MailboxDatabase : Initializing Active Directory server settings for the remote
Windows PowerShell session.
VERBOSE: [08:48:50.689 GMT] Remove-MailboxDatabase : Active Directory session settings for 'Remove-MailboxDatabase'
are: View Entire Forest: 'False', Default Scope: 'xxxx.xxx.local', Configuration Domain Controller:
'XXXXX.xxxxx.xxx.local', Preferred Global Catalog: 'XXXXX.xxxxx.xxx.local', Preferred Domain Controllers:
'{XXXXX.xxxxx.xxx.local }'
VERBOSE: [08:48:50.689 GMT] Remove-MailboxDatabase : Beginning processing Remove-MailboxDatabase
VERBOSE: [08:48:50.720 GMT] Remove-MailboxDatabase : Instantiating handler with index 0 for cmdlet extension agent
"Admin Audit Log Agent".
VERBOSE: [08:48:50.767 GMT] Remove-MailboxDatabase : Current ScopeSet is: { Recipient Read Scope: {{, }}, Recipient
Write Scopes: {{, }}, Configuration Read Scope: {{, }}, Configuration Write Scope(s): {{, }, }, Exclusive Recipient
Scope(s): {}, Exclusive Configuration Scope(s): {} }
VERBOSE: [08:48:50.814 GMT] Remove-MailboxDatabase : Searching objects "Mailbox Database 0118869248" of type
"MailboxDatabase" under the root "$null".
VERBOSE: [08:48:50.845 GMT] Remove-MailboxDatabase : Previous operation run on domain controller
'XXXXX.xxxxx.xxx.local'.
VERBOSE: [08:48:50.923 GMT] Remove-MailboxDatabase : Verifying that there is no associated mailbox user or move request
on the mailbox database "Mailbox Database 0118869248".
VERBOSE: [08:48:50.970 GMT] Remove-MailboxDatabase : Verifying that there is no Microsoft Exchange Mailbox Replication
service request associated with mailbox database "Mailbox Database 0118869248".
VERBOSE: [08:48:51.032 GMT] Remove-MailboxDatabase : The Admin RPC connection is being established with server
"XXXXX.xxxxx.xxx.local".
VERBOSE: [08:48:51.391 GMT] Remove-MailboxDatabase : Checking the status of database "Mailbox Database 0118869248".
VERBOSE: [08:48:51.516 GMT] Remove-MailboxDatabase : Admin Audit Log: Entered Handler:Validate.
VERBOSE: [08:48:51.516 GMT] Remove-MailboxDatabase : Admin Audit Log: Entered ClassFactory:InitializeConfig.
VERBOSE: [08:48:51.594 GMT] Remove-MailboxDatabase : Admin Audit Log: Exited ClassFactory:InitializeConfig.
VERBOSE: [08:48:51.609 GMT] Remove-MailboxDatabase : Admin Audit Log: Exited Handler:Validate.

Confirm
Are you sure you want to perform this action?
Removing mailbox database "Mailbox Database 0118869248".
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"):
VERBOSE: [08:49:13.060 GMT] Remove-MailboxDatabase : Resolved current organization: .
VERBOSE: [08:49:13.060 GMT] Remove-MailboxDatabase : PreInternalProcessRecord on cmdlet extension agent index '0'
returned object changed flag as 'False'.
VERBOSE: [08:49:13.060 GMT] Remove-MailboxDatabase : The Admin RPC connection is being established with server
"XXXXX.xxxxx.xxx.local".
VERBOSE: [08:49:13.075 GMT] Remove-MailboxDatabase : Checking the status of database "Mailbox Database 0118869248".
VERBOSE: [08:49:13.075 GMT] Remove-MailboxDatabase : Dismounting the database, "Mailbox Database 0118869248".
VERBOSE: [08:49:50.328 GMT] Remove-MailboxDatabase : Searching objects "xxxxxx.xxx.local/Microsoft Exchange System
Objects/SystemMailbox{8a7935c2-cd94-4ccd-961f-4a953ea03a38}" of type "ADRecipient" under the root "$null".
VERBOSE: [08:49:50.344 GMT] Remove-MailboxDatabase : Previous operation run on domain controller
'XXXXX.xxxxx.xxx.local'.
VERBOSE: [08:49:50.359 GMT] Remove-MailboxDatabase : Deleting the System Attendant object "xxxxx.xxx.local/Microsoft
Exchange System Objects/SystemMailbox{8a7935c2-cd94-4ccd-961f-4a953ea03a38}".
VERBOSE: [08:49:50.531 GMT] Remove-MailboxDatabase : Previous operation run on domain controller
'XXXXX.xxxxx.xxx.local'.
VERBOSE: [08:49:50.546 GMT] Remove-MailboxDatabase : Deleting monitoring mailboxes from database "Mailbox Database
0118869248".
VERBOSE: [08:49:50.640 GMT] Remove-MailboxDatabase : Deleting "Mailbox Database 0118869248" of type "MailboxDatabase".
VERBOSE: [08:49:50.765 GMT] Remove-MailboxDatabase : Previous operation run on domain controller
'XXXXX.xxxxx.xxx.local'.
WARNING: The specified database has been removed. You must remove the database file located in D:\Program
Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 0118869248\Mailbox Database 0118869248.edb from your
computer manually if it exists. Specified database: Mailbox Database 0118869248
VERBOSE: [08:49:50.796 GMT] Remove-MailboxDatabase : Searching objects of type "MailboxDatabase" with filter
"(OriginalDatabase Equal 8a7935c2-cd94-4ccd-961f-4a953ea03a38)", scope "SubTree" under the root "$null".
VERBOSE: [08:49:50.796 GMT] Remove-MailboxDatabase : Previous operation run on domain controller
'XXXXX.xxxxx.xxx.local'.
VERBOSE: [08:49:50.796 GMT] Remove-MailboxDatabase : Admin Audit Log: Entered Handler:OnComplete.
VERBOSE: [08:49:51.124 GMT] Remove-MailboxDatabase : Admin Audit Log: Exited Handler:OnComplete.
VERBOSE: [08:49:51.139 GMT] Remove-MailboxDatabase : Ending processing Remove-MailboxDatabase

De database is nu succesvol verwijderd.

Vervolgens geprobeerd Exchange volledig te verwijderen van de server. Krijg ik de melding:

There are messages waiting in the following queues: XXXXX\Shadow\3.

Ik heb gekeken met de Exchange Toolbox en ik zie inderdaad berichten voorbij komen. Blijkbaar verwijst er nog steeds iets naar de oude server alhoewel de database er nu niet meer is.

[ Voor 89% gewijzigd door be3a18 op 11-12-2018 10:19 ]

[Satangel]

Ik heb de laatste weken weer problemen (nadat ze toch maanden zijn weggeweest) met het zoeken in de inhoud van PDF's in Outlook. Wat ik al heb geprobeerd;

iFilter herinstalleren
Adobe reader & ifilter eraf doen, rebooten, adobe reader & ifilter herinstalleren

Ik zie alleszins in Indexing --> advanced --> file types dat er bij PDF staat 'registered ifilter not found', terwijl de iFilter echt wel geinstalleerd is.
Heb het probleem met zowel Windows 7 als Windows 10

Iemand een idee? Ik gebruik Outlook 2016 32bit

[Jazzy]

Satangel schreef op woensdag 12 december 2018 @ 16:41:
Iemand een idee? Ik gebruik Outlook 2016 32bit

Je post in het algemene Exchange topic maar als ik je bericht goed lees gaat het echt over Outlook, de client dus. Toch? In dat geval kun je beter een eigen topic openen in Client Software Algemeen.

[Verwijderd]

be3a18 schreef op maandag 10 december 2018 @ 10:20:

Vervolgens geprobeerd Exchange volledig te verwijderen van de server. Krijg ik de melding:

There are messages waiting in the following queues: XXXXX\Shadow\3.

Ik heb gekeken met de Exchange Toolbox en ik zie inderdaad berichten voorbij komen. Blijkbaar verwijst er nog steeds iets naar de oude server alhoewel de database er nu niet meer is.

En heb je wat meer info over die berichten in de queue? Intern of extern verkeer? Naar welke mailboxen willen ze?

[Jazzy]

De shadow queue is een vangnet voor berichten die al verzonden zijn naar een volgende hop. Die melding kun je dus prima negeren.

[be3a18]

Jazzy schreef op donderdag 13 december 2018 @ 11:06:
De shadow queue is een vangnet voor berichten die al verzonden zijn naar een volgende hop. Die melding kun je dus prima negeren.

Dat heb ik uiteindelijk ook gedaan. De oude Exchange server is met succes verwijderd.

[SirDarkAngel]

Kwam deze privilege escalation bug net tegen binnen Exchange. Er is nog geen patch aanwezig, maar je kan de omgeving wel configureren zodat je niet meer kwetsbaar bent. Interessant voor Exchange admins.:

https://dirkjanm.io/abusi...l-away-from-domain-admin/

[Question Mark]

Goed artikel, maar als je als bedrijf ano 2019 nog steeds geen SMB signing afdwingt dan verwacht ik dat er nog wel wat meer securityflaws aanwezig zijn in dat bedrijf...

MS adviseert al tijden lang lang om SMB signing ook te enablen. "Nadeel" is alleen dat de default instelling op disabled staat (behalve voor DC's). Het moet actief enabled worden.

[_dirkjan]

Question Mark schreef op vrijdag 25 januari 2019 @ 10:53:
Goed artikel, maar als je als bedrijf ano 2019 nog steeds geen SMB signing afdwingt dan verwacht ik dat er nog wel wat meer securityflaws aanwezig zijn in dat bedrijf...

Behalve natuurlijk dat deze aanval nog steeds werkt ook al heb je wel SMB signing aanstaan.

[Jazzy]

De updates zijn uit: https://blogs.technet.mic...arterly-exchange-updates/

[HyperBart]

Ik heb het idee dat ik iets mis en ik kan er geen vinger op leggen en het "bugged" me nu al een heel weekend.

Omgeving met 2 Exchange 2010 servers, SRV2 is MBX en SRV1 doet al de andere (interne) rollen, geen edge aanwezig.

Transitie naar Exchange 2016 met unbound namespace, intern extern wordt het mail.klant.be, klant zit volledig op Outlook 2013 of 2016. Alle namespaces zijn intern omgezet en via DNS round robin wordt alles naar de 4 nieuwe EX2016 machines gepoint.

Ik faseer mijn migraties/transities altijd en één van de eerste dingen die ik omleg is CAS functionaliteit. Maar om de een of andere reden, ondanks dat ik Outlook Anywhere heb enabled op de backend en dit point naar mail.klant.be bouwen de clients nog sessies via TCP/RPC op naar de EX2010 CAS. Dat is toch niet normaal? Vanaf het moment dat je de 2016 als proxy'ende CAS er tussen zet bouw je toch MAPI/HTTP normaal op en zou je alleen maar de mail.klant.be naam mogen zien? Of droom ik wat?

[Qwerty-273]

Gaan alle connecties naar de Ex2010 CAS ? Ideale check lijstje is natuurlijk te vinden op het Exchange team blog:
https://techcommunity.mic...e-Environment/ba-p/603945

[be3a18]

OWA ligt bij ons overhoop.

Als ik naar de URL ga krijg ik keurig het inlogscherm. Het certificaat in kwestie is:

Sectigo RSA Domain Validation Secure Server CA, geldig tot 20-1-2021

Na inloggen gaat het echter mis. Dit geeft het volgende scherm:

Server Error in '/owa' Application.
https://xxxx.xxx.nl/owa/a...ror=SSLCertificateProblem
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: https://xxxx.xxx.nl/owa/a...ror=SSLCertificateProblem

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[HttpException (0x80004005): https://xxxx.xxx.nl/owa/a...or=SSLCertificateProblem]
Microsoft.Exchange.HttpProxy.FbaModule.OnBeginRequestInternal(HttpApplication httpApplication) +437
Microsoft.Exchange.HttpProxy.<>c__DisplayClass16_0.<OnBeginRequest>b__0() +1641
Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate) +35
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +223
System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +213
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +91


Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.7.3429.0

In de Event Log op de Exchange Server (2016 Standaard) wordt een ASP.NET.4.0... event geregistreerd.

Log Name: Application
Source: ASP.NET 4.0.30319.0
Date: 10/4/2019 10:39:49 AM
Event ID: 1309
Task Category: Web Event
Level: Warning
Keywords: Classic
User: N/A
Computer: xxxxx
Description:
Event code: 3005

Ik kom wel meldingen hierover tegen via Google maar die zijn toch allemaal iets anders. Dan gaat het over corrupte of missende bestanden. Ik zag verder kort geleden dat er weer een update is voor Exchange 2016, die staat er nog niet. We zijn bij tot die laatste versie.

[DDX]

Iemand idee hoe ik kan zorgen dat ik https://servernaam/owa/healthcheck.htm ook via http bereikbaar kan maken ?
Ik wil de ssl settings van onze servers wat veiliger zetten, maar loop dan tegen het probleem aan dat onze hardware loadbalancers dan niet meer kunnen connecten.
Al wat oudere hardware, maar voor het loadbalancen doen ze prima hun werk.
En als ik de healthcheck over http kan laten lopen kunnen ze nogsteeds de ssl poort loadbalancen.

edit: opgelost via stukje code die bereikbaar is op http poort :

code:

<%@Language="C#" %>
<%
    var request = System.Net.WebRequest.Create("https://servernaam/owa/healthcheck.htm");
    var response = request.GetResponse();
    using (var reader = new System.IO.StreamReader(response.GetResponseStream()))
    {
        Response.Write(reader.ReadToEnd());
    }
%>

[ Voor 29% gewijzigd door DDX op 04-10-2019 16:18 ]

[be3a18]

Ik heb de Office Exchange Analyzer gedraaid om na te gaan of daar misschien een probleem is. De volgende 'fail'-melding komt daarbij naar voren:

Failed items:
• - Exchange Server 2016 CU12 and .NET Framework 4.7.1 are not supported together.

Echter, daarboven staat bij de summary of the Exchange servers:

Exchange Server 2016 CU12 .NET Framework 4.7.1

Ik besef nu ook dat ik inmiddels 2 CU's achter loop, maar dan toch. Eerst staat er dat 4.7.1. geïnstalleerd is daarna komt er een foutmelding over.

Verklaart dit overigens de OWA problemen?

[Jazzy]

be3a18 schreef op maandag 7 oktober 2019 @ 13:25:
Failed items:
• - Exchange Server 2016 CU12 and .NET Framework 4.7.1 are not supported together.

Dat klopt niet, zie de supportability matrix: https://docs.microsoft.co...trix?view=exchserver-2019

Beste kun je even feedback geven aan de maker van die tool, zal waarschijnlijk een bugje zijn.

[be3a18]

Jazzy schreef op maandag 7 oktober 2019 @ 13:32:
[...]

Dat klopt niet, zie de supportability matrix: https://docs.microsoft.co...trix?view=exchserver-2019

Beste kun je even feedback geven aan de maker van die tool, zal waarschijnlijk een bugje zijn.

Daar had ik inderdaad al gekeken, daarom vond ik het ook zo vreemd.

Gaat de installatie van een CU de OWA problemen oplossen?

[Turdie]

be3a18 schreef op maandag 7 oktober 2019 @ 13:39:
[...]


Daar had ik inderdaad al gekeken, daarom vond ik het ook zo vreemd.

Gaat de installatie van een CU de OWA problemen oplossen?

Je kunt OWA verwijderen en opnieuw aanmaken vaak lost dat problemen wel op, heb daar eerder al iets over geschreven hier op Tweakers. Hier staat het ook beschreven:
https://theitbros.com/rec...ies-exchange-server-2016/

[ Voor 12% gewijzigd door Turdie op 07-10-2019 13:42 ]

[be3a18]

shadowman12 schreef op maandag 7 oktober 2019 @ 13:41:
[...]


Je kunt OWA verwijderen en opnieuw aanmaken vaak lost dat problemen wel op, heb daar eerder al iets over geschreven hier op Tweakers. Hier staat het ook beschreven:
https://theitbros.com/rec...ies-exchange-server-2016/

Oke. Ik ga het doornemen, bedankt.

[be3a18]

Ik heb de procedure gevolgd (behalve het backend verhaal, van mijn collega begrijp ik dat Outlook er dan mee stopt) maar het heeft helaas niet geholpen.

[Turdie]

be3a18 schreef op maandag 7 oktober 2019 @ 14:39:
Ik heb de procedure gevolgd (behalve het backend verhaal, van mijn collega begrijp ik dat Outlook er dan mee stopt) maar het heeft helaas niet geholpen.

Heb je recent wijzingen uitgevoerd aan de Exchange certificaten?

[be3a18]

shadowman12 schreef op maandag 7 oktober 2019 @ 14:47:
[...]


Heb je recent wijzingen uitgevoerd aan de Exchange certificaten?

Nee, het certificaat wat actief is bij het aanroepen van OWA is gewoon geldig en niet verlopen. Na het inloggen gaat het mis. We kunnen ook niet meer in het Exchange Admin Centre.

[Turdie]

be3a18 schreef op maandag 7 oktober 2019 @ 14:53:
[...]


Nee, het certificaat wat actief is bij het aanroepen van OWA is gewoon geldig en niet verlopen. Na het inloggen gaat het mis. We kunnen ook niet meer in het Exchange Admin Centre.

Dan is er denk een issue met die Back-End sites, die zul je dan toch opnieuw moeten aanmaken. Zou ik buiten werktijd doen als er mensen Outlook niet gebruiken.

[be3a18]

Ik loop nu tegen een ander probleem aan. Ik probeer CU13 te installeren. Echter, enige tijd geleden is een language pack (nl-NL) geïnstalleerd (voor voicemail). Bij het starten van de Setup krijg ik de melding dat die eerst moet worden gedeïnstalleerd. Dat krijg ik dus niet voor mekaar.

Ik probeer op de officiële manier via Setup.exe /RemoveUmLanguagePack:<nl-NL> en ik probeer daarbij rekening te houden met wat er over vermeld wordt (you can't use the Setup.exe file that's located in the \Bin folder to remove a UM language pack after you've installed any updates. You must use the Setup.exe file from the Exchange 2013 DVD or the downloaded source files. If you don't, you'll see the following error: There is a version mismatch between the running application and the installed application).

Er gaat dus inderdaad iets mis maar dat kan ik zo snel niet zien.

Na de installatie van het language pack zijn alleen maar CU's voor Windows Server 2016 geïnstalleerd.

[pitchdown]

Ik zit op mijn beide exchange 2016-servers 14 GB aan folders staan in de volgende map:
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem

Hierin staan oudere versies van OWA (vanaf 2016).
Is het mogelijk om deze oude mappen te verwijderen zonder dat er iets instort?

[FREAKJAM]

pitchdown schreef op maandag 14 oktober 2019 @ 14:01:
Ik zit op mijn beide exchange 2016-servers 14 GB aan folders staan in de volgende map:
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem

Hierin staan oudere versies van OWA (vanaf 2016).
Is het mogelijk om deze oude mappen te verwijderen zonder dat er iets instort?

Deze post op Reddit al gezien? En dan in het bijzonder de opmerking van user 'sembee2'.

This is due to the design of Exchange. The CAS role does not belong to the Mailbox. Therefore you could access the mailbox from any other server. As the version of OWA that is presented to you is dictated by the version of Exchange that your mailbox is located on (and version here I am referring to build, not 2016/2013 etc), then it will hold the older versions so that you can support accessing the different versions in a mixed version site.
If you were to do a new installation of Exchange 2016 (say CU11) and still had CU5 servers, then you would OWA wouldn't work correctly if you accessed it from the CU11 server - the versions would need to be copied across.

On a single server this is obviously not so much of a problem, but clearing them out is not something i have ever done or seen recommended elsewhere or by Microsoft.

[pitchdown]

FREAKJAM schreef op maandag 14 oktober 2019 @ 14:36:
[...]


Deze post op Reddit al gezien? En dan in het bijzonder de opmerking van user 'sembee2'.


[...]

Hieruit zou ik kunnen concluderen dat ik als beide servers de laatste versie draaien er geen issue zal ontstaan?

[be3a18]

Gisteravond geprobeerd het language pack te verwijderen. Op een Microsoft forum las ik dat dit kon via msiexec.exe /X{dedffb64-42ec-4e26-0413-430e86df378c} waarbij dat laatste de register sleutel is voor het taalpakket.

In de event viewer zie ik vervolgens staan:

Windows Installer removed the product. Product Name: Microsoft Exchange Client Language Pack - Dutch. Product Version: 15.1.1713.5. Product Language: 1033. Manufacturer: Microsoft Corporation. Removal success or error status: 0

Vervolgens herstart gedaan (werd overigens niet om gevraagd). Desondanks blijft de Setup van de CU beweren dat er een language pack op staat.

[be3a18]

Sinds enige dagen krijgen onze Outlook gebruikers om de zoveel tijd de vraag om hun wachtwoord in te voeren. Beetje vreemd want iedereen is lid van het Windows domein en behalve bij Outlook/Exchange zijn er geen problemen.

As we speak heb ik dat zelf ook. Rechtsonder staat Wachtwoord nodig. Als ik er op klik verdwijnt de boodschap en staat er Vervonden met Microsoft Exchange.

Ik heb verder de mailbox van een collega open staan die ik met geen mogelijkheid kan sluiten, wat ik ook probeer. De mailbox staat niet als toegevoegde mailbox bij de Account instellingen.

Toch krijg ik de melding dat dit account gekoppeld is aan mijn e-mail account. Wat dus niet zo is.

Geldt overigens voor meerdere mailboxen die ik allemaal niet kan sluiten.

[Jazzy]

be3a18 schreef op dinsdag 12 november 2019 @ 11:10:
Ik heb verder de mailbox van een collega open staan die ik met geen mogelijkheid kan sluiten, wat ik ook probeer. De mailbox staat niet als toegevoegde mailbox bij de Account instellingen.

Toch krijg ik de melding dat dit account gekoppeld is aan mijn e-mail account. Wat dus niet zo is.

Geldt overigens voor meerdere mailboxen die ik allemaal niet kan sluiten.

Heb je toevallig Full Access op deze mailboxes? Dan deze even verwijderen en indien nodig opnieuw toepassen maar dan met -AutoMapping $false.

[Qwerty-273]

Gebruik je ook Lync/Skype? Gebruikers accounts die locken en automatisch unlocken na x minuten?

[be3a18]

Jazzy schreef op dinsdag 12 november 2019 @ 11:33:
[...]
Heb je toevallig Full Access op deze mailboxes? Dan deze even verwijderen en indien nodig opnieuw toepassen maar dan met -AutoMapping $false.

Oke. Vanuit ECP verwijderen en dan met Powershell weer toevoegen dus

Wat misschien ook speelt is dat we voor een bepaalde webapp gebruik maken van een exchange imporsonation account wat alle rechten heeft op alle mailboxen voor het uitlezen van de agenda's. Ik heb dat in eerste instantie gebruikt met specifiek rechten toepassen op de agenda's alleen maar dat werkte niet. Dit speciale account is alleen in gebruik voor de webapp, meer niet. Op een andere Windows server draait een Scheduled task die om de zoveel minuten alles uitleest.

Verder gebruiken we ook de Skype voor Bedrijven client (even reageren op commentaar hieronder).

Onze bedrijfspolicy is verder de PC te locken via Windows toetst + l zodra je niet achter je PC zit.

Alle het genoemde hierboven heeft tot voor kort geen problemen gegeven.

[ Voor 4% gewijzigd door be3a18 op 12-11-2019 13:33 ]

[Jazzy]

Als het account EWS Impersonation gebruikt dan hoef je geen mailbox (folder) permissies te zetten. Impersonation is juist dat het account toestemming heeft grekregen om de mailbox te benaderen als de gebruiker zelf.

[be3a18]

Jazzy schreef op dinsdag 12 november 2019 @ 14:48:
Als het account EWS Impersonation gebruikt dan hoef je geen mailbox (folder) permissies te zetten. Impersonation is juist dat het account toestemming heeft grekregen om de mailbox te benaderen als de gebruiker zelf.

Ik heb dit enige tijd geleden al ingesteld dus ik kan me even niet meer precies herinneren hoe ik dit gedaan. Volgens mij vanuit Powershell en via de officiële Microsoft documentatie. Ik weet ook nog dat ik niet expliciet extra rechten opgaf het niet werkte. De agenda gegevens werden dan niet volledig uitgelezen wat we wel wilden.

Het punt is even of dit de problemen kan veroorzaken

[be3a18]

Zonet weer een verzoek om mijn wachtwoord in te voeren (wachtwoord invoeren lukt trouwens niet, ik kan alleen maar Annuleren). Vervolgens komt rechtsonder in Outlook te staan Wachtwoord nodig. Als ik daar vervolgens op klik kan ik niks invoeren en komt er weer te staan Verbonden met Microsoft Exchange.

[ Voor 13% gewijzigd door be3a18 op 13-11-2019 15:24 ]

[DDX]

be3a18 schreef op dinsdag 12 november 2019 @ 11:10:
Sinds enige dagen krijgen onze Outlook gebruikers om de zoveel tijd de vraag om hun wachtwoord in te voeren. Beetje vreemd want iedereen is lid van het Windows domein en behalve bij Outlook/Exchange zijn er geen problemen.

Ik krijg hier bij ons ook meldingen van gebruikers met dit probleem sinds een aantal dagen.
(Exchange 2016 icm Office 2019)
De paar mensen die dit vandaag gemeld hebben, heb ik gevraagd te rebooten maar weet nog niet of dit het oplost.
Maar toevallig had ik jouw bericht gelezen en dus lijkt een algemener probleem oid ?

[be3a18]

DDX schreef op woensdag 13 november 2019 @ 15:53:
[...]


Ik krijg hier bij ons ook meldingen van gebruikers met dit probleem sinds een aantal dagen.
(Exchange 2016 icm Office 2019)
De paar mensen die dit vandaag gemeld hebben, heb ik gevraagd te rebooten maar weet nog niet of dit het oplost.
Maar toevallig had ik jouw bericht gelezen en dus lijkt een algemener probleem oid ?

Ik heb geen idee. Misschien dat de andere Tweakers hier meer over weten.

Ik heb gisteren getest met OWA en daar speelt het probleem niet. Het is echt de combinatie Exchange met Outlook 2016/2019. Ik had 2019 geïnstalleerd met de hoop dat dit de problemen oploste maar nee dus.

[DDX]

Ik heb er zelf nog helemaal geen last van gehad en hoor ook niet heel veel mensen erover.

[be3a18]

Ik log de Wachtwoord invoerpogingen nu tot op de seconde:

Deze melding komt in de Event log als het mis gaat bij mij:

An account was logged off.

Subject:
Security ID: SYSTEM
Account Name: <naam van de server>$
Account Domain: <naam van het domein>
Logon ID: 0x567CAAB

Logon Type: 3

This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.

Een eerdere melding is (precies op het geregistreerde tijdstip):

An account was logged off.

Subject:
Security ID: <domein>\<mijn username>
Account Name: <mijn username>
Account Domain: domein naam
Logon ID: 0x55C306E

Logon Type: 3

This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.

[ Voor 30% gewijzigd door be3a18 op 13-11-2019 16:24 ]

[be3a18]

Als ik Google op This event... kom ik onder andere dit tegen:

https://community.spicewo...ect-does-not-exist?page=2

Het is alleen vreemd dat dit pas de laatste 1½ week optreedt.

[be3a18]

Ik zit gewoon achter mijn PC te werken, ik lock geen schermen en ik log niet uit maar desondanks in de Event viewer van mijn eigen PC.

Er is een account afgemeld.

Onderwerp:
Beveiligings-id: SYSTEM
Accountnaam: PROG-PC12$
Accountdomein: <domein naam>
Aanmeldings-id: 0x271C938B0

Aanmeldingstype: 3

Deze gebeurtenis wordt gegenereerd wanneer een aanmeldingssessie wordt vernietigd. De gebeurtenis kan met behulp van de aanmeldings-id positief worden afgestemd met een aanmeldingsgebeurtenis. Aanmeldings-id's zijn alleen uniek wanneer de computer opnieuw is opgestart.

De logica hiervan ontgaat mij.

[DDX]

Een reboot lost het niet op bij de 4 gebruikers die het inmiddels gemeld hebben.
Als ze op cancel drukken lijkt alles te werken, mail komen gewoon binnen agenda's ed kunnen geopend worden.

Gelukkig maar bij paar mensen (en ikzelf dus nergens last van) want heb geen idee waar dit probleem opeens vandaan komt.

[Question Mark]

be3a18 schreef op woensdag 13 november 2019 @ 16:10:
[...]
Ik heb gisteren getest met OWA en daar speelt het probleem niet. Het is echt de combinatie Exchange met Outlook 2016/2019. Ik had 2019 geïnstalleerd met de hoop dat dit de problemen oploste maar nee dus.

Start Outlook eens op in safe mode? Zou best kunnen dat je probleem in één of andere add-on zit. Je gebruikt ook Skype for Business in je omgeving, en vanuit je postgeschiedenis weet ik dat ook die omgeving niet vlekkeloos draait. Zou goed kunnen dat de Skype for Business plugin in Outlook dit (indirect) veroorzaakt...

[be3a18]

Question Mark schreef op vrijdag 15 november 2019 @ 14:49:
[...]

Start Outlook eens op in safe mode? Zou best kunnen dat je probleem in één of andere add-on zit. Je gebruikt ook Skype for Business in je omgeving, en vanuit je postgeschiedenis weet ik dat ook die omgeving niet vlekkeloos draait. Zou goed kunnen dat de Skype for Business plugin in Outlook dit (indirect) veroorzaakt...

Zojuist geprobeerd. Krijg na 20 seconden de melding of ik verbinding wil maken met PubliekeMappen@<naam organisatie>.nl...

Slaat helemaal nergens op.

[mhogen]

Zal dit helpen?
You can verify this by using the utilities Fiddler or TCPView, keeping track of the attempts to connect to the servers autodiscover-s.outlook.com and outlook.office365.com.

To disable this check, go to the registry key HKEY_CURRENT_USER\Software \Microsoft\Office\16.0\Outlook \AutoDiscover and create a DWORD parameter named ExcludeExplicitO365Endpoint and value 1. Restart Outlook.

The ExcludeExplicitO365Endpoint registry parameter is applicable to Outlook 2016 version 16.0.6741.2017 and higher (this parameter is additional to the list of parameters that determine the types of checks when Outlook starts: see an article Slow Exchange AutoDiscover in Outlook 2016).

You can make changes to the registry with the following command:

reg add HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover /t REG_DWORD /v ExcludeExplicitO365Endpoint /d 1

http://woshub.com/outlook-keeps-prompting-credentials/

Dit was de oplossing bij een klant ons.

[ Voor 3% gewijzigd door mhogen op 15-11-2019 15:20 ]

[be3a18]

mhogen schreef op vrijdag 15 november 2019 @ 15:20:
Zal dit helpen?
You can verify this by using the utilities Fiddler or TCPView, keeping track of the attempts to connect to the servers autodiscover-s.outlook.com and outlook.office365.com.

To disable this check, go to the registry key HKEY_CURRENT_USER\Software \Microsoft\Office\16.0\Outlook \AutoDiscover and create a DWORD parameter named ExcludeExplicitO365Endpoint and value 1. Restart Outlook.

The ExcludeExplicitO365Endpoint registry parameter is applicable to Outlook 2016 version 16.0.6741.2017 and higher (this parameter is additional to the list of parameters that determine the types of checks when Outlook starts: see an article Slow Exchange AutoDiscover in Outlook 2016).

You can make changes to the registry with the following command:

reg add HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover /t REG_DWORD /v ExcludeExplicitO365Endpoint /d 1

http://woshub.com/outlook-keeps-prompting-credentials/

Dit was de oplossing bij een klant ons.

De bovengenoemde waarde is niet aanwezig op mijn PC maar dat komt waarschijnlijk omdat ik inmiddels Office 2019 Prof heb geïnstalleerd. Ik kan nog even proberen of dit wil op een PC waar Office 2016 is geïnstalleerd.

[ Voor 3% gewijzigd door be3a18 op 15-11-2019 15:40 ]

[thieske1]

be3a18 schreef op vrijdag 15 november 2019 @ 15:02:
[...]


Zojuist geprobeerd. Krijg na 20 seconden de melding of ik verbinding wil maken met PubliekeMappen@<naam organisatie>.nl...

Slaat helemaal nergens op.

Deze melding geeft toch best duidelijk aan dat er iets van public folders zit te bitchen in je outlook omgeving.
Is er toevallig recentelijk iets gebeurd met je public folder database?

[be3a18]

thieske1 schreef op vrijdag 15 november 2019 @ 15:43:
[...]

Deze melding geeft toch best duidelijk aan dat er iets van public folders zit te bitchen in je outlook omgeving.
Is er toevallig recentelijk iets gebeurd met je public folder database?

Voor zover ik weet niet. Ik en mijn collega hebben niks aangepast. Misschien is er iets corrupt.

[thieske1]

be3a18 schreef op vrijdag 15 november 2019 @ 15:49:
[...]


Voor zover ik weet niet. Ik en mijn collega hebben niks aangepast. Misschien is er iets corrupt.

Kan je onderstaande PowerShell commando eens uitvoeren met de mailboxdatabase waarop jouw mailbox zit?
Get-MailboxDatabase -Identity "mailboxdatabase" | ft name,publicfolderdatabase

[be3a18]

thieske1 schreef op vrijdag 15 november 2019 @ 16:16:
[...]

Kan je onderstaande PowerShell commando eens uitvoeren met de mailboxdatabase waarop jouw mailbox zit?
Get-MailboxDatabase -Identity "mailboxdatabase" | ft name,publicfolderdatabase

Ik kijk er vanavond even naar. Nogal druk momenteel en iedereen hier is over een kwartier toch nog naar huis.

[be3a18]

De problemen zijn nu 'opgelost' door de volgende Windows register aanpassing:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

Deze key moest ik apart aanmaken omdat er nog geen dergelijke entry was.

Wij maken ook nog gebruik van Office 365 alleen zie ik de link zo even niet.

[DDX]

Hier lijkt probleem opgelost nadat we eind vorige week de servers voorzien hebben van laatste security updates en hebben gereboot.
Gebruikers die het gemeld hadden hebben er deze week nog geen last van gehad.

[be3a18]

DDX schreef op woensdag 20 november 2019 @ 13:33:
Hier lijkt probleem opgelost nadat we eind vorige week de servers voorzien hebben van laatste security updates en hebben gereboot.
Gebruikers die het gemeld hadden hebben er deze week nog geen last van gehad.

Niet al te lang voor de problemen opdoken kregen we wat Microsoft Office updates voor de kiezen. Misschien zat daar iets tussen wat de problemen veroorzaakte.

[DDX]

be3a18 schreef op woensdag 20 november 2019 @ 13:39:
[...]


Niet al te lang voor de problemen opdoken kregen we wat Microsoft Office updates voor de kiezen. Misschien zat daar iets tussen wat de problemen veroorzaakte.

Zou ook kunnen ja, aangezien Office (2019 die wij gebruiken) zelf de updates installeert buiten windows update om.

[Ultra]

Heeft iemand goede of slecht ervaringen met backup software voor 'traditionele' backups van Exchange DAGs? Ik heb nu in een omgeving Windows backup lopen, maar deze werkt eigenlijk alleen betrouwbaar als er een historie van niet mer dan twee kopieën bewaard wordt. De mailbox databases zijn nu aan de grote kant, misschien dat dat een van de oorzaken is .

[Mexikola]

Even een post voor awareness. Er is een exploit gevonden in alle versies van exchange en Microsoft heeft updates uitgebracht. Deze exploit maakt het mogelijk om code uit te voeren op de exchange server. Ze hebben wel minimaal een gebruikers login nodig.

Link met microsoft updates:
https://portal.msrc.micro...ce/advisory/CVE-2020-0688

Blog met voorbeeld:
https://www.thezdi.com/bl...-fixed-cryptographic-keys

[zonderbloem]

Nieuwe Exchange CU updates zijn uit

https://docs.microsoft.co...ates?view=exchserver-2019

[Oogje]

En we kunnen weer gaan patchen buiten de CU om: https://support.microsoft...ange-server-2019-and-2016