Differences

This shows you the differences between two versions of the page.

View differences: Side by SideInline Go

Link to this comparison view

Both sides previous revisionPrevious revision 2026/10/19 08:31 jp 2026/10/19 08:31 jp 2026/10/19 08:30 jp 2026/10/19 08:29 jp 2026/10/19 08:28 jp 2026/10/19 08:26 jp 2026/10/19 08:15 jp 2026/10/19 08:10 jp 2026/10/19 08:10 jp 2026/10/19 08:05 jp 2026/10/19 08:00 jp 2026/10/19 07:58 jp 2026/10/19 07:56 jp 2026/10/19 07:55 jp 2026/10/19 07:52 jp createdGo Next revision		Previous revision 2026/10/19 08:31 jp 2026/10/19 08:31 jp 2026/10/19 08:30 jp 2026/10/19 08:29 jp 2026/10/19 08:28 jp 2026/10/19 08:26 jp 2026/10/19 08:15 jp 2026/10/19 08:10 jp 2026/10/19 08:10 jp 2026/10/19 08:05 jp 2026/10/19 08:00 jp 2026/10/19 07:58 jp 2026/10/19 07:56 jp 2026/10/19 07:55 jp 2026/10/19 07:52 jp createdGo
проблема_с_календарями_и_eventid_1309 [2026/10/19 07:55] – jp		проблема_с_календарями_и_eventid_1309 [2026/10/19 08:31] (current) – jp
Line 6:		Line 6:
	Ошибка при подготовке к отправке сообщения о совместном доступе		Ошибка при подготовке к отправке сообщения о совместном доступе
-	При этом, доступ к календарям через //OWA// работал нормально. Диагностика проблем почтовых клиентов ни к чему не привела - в логах //Outlook// ничего интересного не было обнаружено.	+	При этом, доступ к календарям через //OWA// работал нормально. Диагностика проблем почтовых клиентов ни к чему не привела - в логах //Outlook// ничего интересного не было обнаружено. В одном и том же почтовом клиенте могла работать одна запись, но не работать другая.
		+
		+	Проверка и просмотр прав на календари тоже ничего не показала. Командлет не показывал чего-то, что могло представлять проблему (вроде существующих прав, которые теперь дублируются при открытии общего доступа).
		+
		+	Get-MailboxFolderPermission "owner@domain.ru:\Календарь"
		+	В определенный момент диагностики я обнаружил, что ящики пользователи, у которых календари работают и пользователи, у которых они не работают - расположены В РАЗНЫХ базах //Exchange//, которые в свою очередь расположены на РАЗНЫХ серверах группы высокой доступности //DAG//.
		+
		+	На следующем этапе самый очевидный шаг - почитать журналы событий на проблемном сервере и сравнить их с работающим.
		+
		+	Подозрительное событие обнаружилось довольно быстро:
		+
		+	;#;
		+	{{:exchange:exchange_1309_asp_error.jpg|}}
		+	;#;
		+
		+	Беглый осмотр конфигурации IIS и пулов ничего не показал
		+
		+	<code>
		+	Import-Module WebAdministration
		+
		+	Get-Website | Select-Object Name,State,Bindings,ApplicationPool
		+
		+	Get-WebApplication -Site "Exchange Back End" |  Select-Object Path,ApplicationPool
		+
		+	Get-ChildItem IIS:\AppPools | Where-Object Name -match 'EWS|Exchange' | Select-Object Name,State
		+	</code>
		+
		+	В логах фигурирует интересная деталь: PID проблемного процесса. Узнаем какому пулу он принадлежит:
		+
		+	& "$env:windir\System32\inetsrv\appcmd.exe" list wp
		+	А также посмотрим - что у него с потреблением памяти:
		+
		+	<code>
		+	Get-Process w3wp |
		+	Sort-Object HandleCount -Descending |
		+	Select-Object Id,ProcessName,HandleCount,
		+	@{N='PrivateMemory_GB';E={[math]::Round($_.PrivateMemorySize64/1GB,2)}}
		+	</code>
		+
		+	Последний код позволил обнаружить кое-что интересное, а именно дату запуска процесса, с которой на момент диагностики прошло уже около 6 месяцев.
		+	<code>
		+	Id               : 493308
		+	ProcessName      : w3wp
		+	StartTime        : 18.05.2026 20:46:20
		+	Handles          : 9391
		+	PrivateMemory_GB : 3,72
		+	WorkingSet_GB    : 3,28
		+	</code>
		+
		+	Ранее мы узнали, что процесс принадлежит пулу //MSExchangeServicesAppPool//.
		+
		+	Разумным решением представляется подобрать удобное время и попробовать перезапустить пул.
		+	<code>
		+	Import-Module WebAdministration
		+
		+	Restart-WebAppPool -Name "MSExchangeServicesAppPool"
		+	</code>
		+
		+	Мне повезло: сразу после рестарта ошибка 1309 пропала из лога, а механизм общего доступа к календарям заработал!
		+
		+	{{tag>Exchange Microsoft Mail PowerShell OWA Outlook IIS}}