<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Windows Server 2008R2 on Twistedminds</title><link>https://twistedminds.ru/tags/windows-server-2008r2/</link><description>Recent content in Windows Server 2008R2 on Twistedminds</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 12 May 2012 10:34:55 +0000</lastBuildDate><atom:link href="https://twistedminds.ru/tags/windows-server-2008r2/index.xml" rel="self" type="application/rss+xml"/><item><title>Перенос Windows DHCP сервера</title><link>https://twistedminds.ru/2012/05/moving-windows-dhcp-server/</link><pubDate>Sat, 12 May 2012 10:34:55 +0000</pubDate><guid>https://twistedminds.ru/2012/05/moving-windows-dhcp-server/</guid><description>&lt;p&gt;В жизни бы не подумал, что мне потребуется это знание больше одного раза, а случилось так, что за последнюю неделю потребовалось перенести аж три штуки.&lt;/p&gt;
&lt;p&gt;И если один из трех перенесся нормально простой операцией Архивировать &amp;gt; Восстановить, то с двумя другими возникла следующая проблема: база восстанавливалась, но вкладка арендованные адреса (leases) была девственно пуста, более того при попытке доступа к ней в журнале событий возникала ошибка:&lt;/p&gt;
&lt;p&gt;&lt;code&gt;Possible Memory Leak.  Application (&amp;amp;#8220;C:\Windows\system32\mmc.exe&amp;amp;#8221; &amp;amp;#8220;C:\Windows\system32\dhcpmgmt.msc&amp;amp;#8221; )&lt;/code&gt;&lt;/p&gt;</description></item><item><title>Citrix XenApp 6.5 – невозможность подключения к ферме после применения групповых политик</title><link>https://twistedminds.ru/2012/02/xenapp-unable-to-connect-to-farm-after-group-policy-update/</link><pubDate>Fri, 17 Feb 2012 06:41:49 +0000</pubDate><guid>https://twistedminds.ru/2012/02/xenapp-unable-to-connect-to-farm-after-group-policy-update/</guid><description>&lt;p&gt;[&lt;img src="https://twistedminds.ru/wp-content/uploads/2012/02/XenAppLogo.png" alt="XenApp Logo" title="XenApp Logo"&gt;][1]Если в результате применения групповой политики (легко повторить баг выполнив gpupdate /force) ваши сервера Citrix XenApp становятся недоступны для пользователей и к примеру возникают ошибки вида
&lt;code&gt;Возникла ошибка при создании запрошенного подключения.&lt;/code&gt;
на портале опубликованных приложений, а qfarm /load возвращает отчет о том, что сервер запрещает новые подключения&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;C:\Users\administrator&amp;gt;qfarm /load
Server Name Server Load Load Throttling Load Logon Mode
——————– ———– ——————– ——————-
CTRX0 200 0 ProhibitLogons
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;значит, скорее всего, вы натолкнулись на этот досадный баг.
Не смотря на то, что Citrix об этом известно бог знает сколько патча, к несчастью, нет, но есть официальный workaround – установить значение ключа реестра fDenyTSConnections, расположенного по пути
&lt;code&gt;HKEY\_LOCAL\_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server&lt;/code&gt;
в “0”.
На сколько я знаю баг затрагивает XenApp 6.5 (некоторые жалуются и на XenApp 6), установленном на Windows Server 2008R2 с Service Pack 1.&lt;/p&gt;</description></item><item><title>Проблема с установкой SP1 на Windows 2008R2</title><link>https://twistedminds.ru/2011/12/sp1-win2k8r2-installation-issue/</link><pubDate>Thu, 01 Dec 2011 08:49:19 +0000</pubDate><guid>https://twistedminds.ru/2011/12/sp1-win2k8r2-installation-issue/</guid><description>&lt;p&gt;После того, как я устал смотреть на нашего одмина, запускающего по 12му разу sfc /scannow после неудачной ошибки обновления до SP1 сервера пришлось взять дело в свои руки.
В event viewer были следующие ошибки:
&lt;code&gt;Установка пакета обновления завершилась с ошибкой; код ошибки: 0x800706be.&lt;/code&gt;&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;Имя сбойного приложения: TrustedInstaller.exe, версия: 6.1.7600.16385, отметка времени: 0x4a5bc4b0
Имя сбойного модуля: ntdll.dll, версия: 6.1.7600.16695, отметка времени 0x4cc7b325
Код исключения: 0xc00000fd
Смещение ошибки: 0x0000000000054a07
Идентификатор сбойного процесса: 0xf9c
Время запуска сбойного приложения: 0x01ccaffe65793418
Путь сбойного приложения: C:\Windows\servicing\TrustedInstaller.exe
Путь сбойного модуля: C:\Windows\SYSTEM32\ntdll.dll
Код отчета: 50dd7494-1bf4-11e1-848e-000c29097f71```
```Служба Установщик модулей Windows была неожиданно завершена.
Это произошло 1 раз(а). Следующее корректирующее действие будет предпринято через 120000 мсек: Перезапуск службы.```
Вспоминая проблемы с установкой SP1 для Vista в свое время, я отправился искать System Update Readiness Tool для Windows 2008 R2 и, в общем-то, [не обломался](http://www.microsoft.com/downloads/ru-ru/details.aspx?familyid=c4b0f52c-d0e4-4c18-aa4b-93a477456336&amp;amp;displaylang=ru &amp;#34;System Update Readiness Tool for Windows 2008R2&amp;#34;).
Readiness tool успешно отработал, но в отличии от Vista Service Pack ставиться все равно не хотел. CheckSUR.log можно найти найти в каталоге
```C:\Windows\Logs\CBS```
и выяснить кто всему виной. В моем случае это было
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Unavailable repair files:
servicing\packages\Package_for_KB2586448_RTM&lt;del&gt;31bf3856ad364e35&lt;/del&gt;amd64&lt;del&gt;6.1.1.2.mum
servicing\packages\Package_for_KB2586448_RTM&lt;del&gt;31bf3856ad364e35&lt;/del&gt;amd64&lt;/del&gt;6.1.1.2.cat&lt;/p&gt;</description></item></channel></rss>