New blog on TechNet

I forgot to update this blog with news that I’m not going to update it anymore because I moved all my technical notes to the new place on TechNet http://blogs.technet.com/b/sergiyt/

I’ll get back here only to answer possible comments or when I decide to close my TechNet blog

Cheers,

Sergiy

Remote Tools don’t work in Windows 7 x64 client

On my current project I found weird thing when SCCM Remote Tools work without any problem on Windows 7 x32 client but failed to run or ask me about local admin credentials to connect to Windows x64 client.

I fixed this by changing permissions for RCLaunch.exe file. I granted Read/Execute permissions for “ConfigMgr Remote Control Users”  group to the file located in Windows 7 x64 OS \Windows\SysWOW64\CCM\clicomp\RemCtrl\RCLaunch.exe.

After that Remote Tolls started to work fine.

Change default logon domain name in the Windows 7 logon screen

This technical solution is not connected to the SCCM or OpsMgr which are my focus technologies but anyway I want to share it here. I have following customer environment: 

1. Windows 7 computers joined to domain A in the city A and we have users in same domain as well
2. We have users in the city B with domain B and they use Windows 7 computers joined to domain A
3. There is a two-way, transitive trust relationship between domain A and domain B 

Everything was OK until users from domain B told me that they want to login to Windows 7 computers (joined to domain A) without typing domainB\username. I didn’t have solution off the top of my head and I made quick Technet search which gave me this article http://support.microsoft.com/kb/555050. Unfortunately  this solution didn’t work as is on Windows 7 OS. First rational idea was to use domain GPO to set DefaultLogonDomain parameter but we use only one domain GPO for Windows 7 computers and create new one for users from domain B wasn’t fancy option.

Solution was come from an idea to trace registry settings after I applied local GPO with DefaultLogonDomain parameter and as result I put this REG file as a task to deployment SCCM task sequence.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

“DefaultLogonDomain”=”DOMAINB”

Distribution of application package with huge folder structure took too long on BITS enabled DP

During my current project I run into problem when tried to distribute Adobe Acrobat Pro 9.3.4 package from BITS enabled DP to Windows 7 x86 client computer and it took up to 10 hours. Package itself contains 1017 folders and 12552 files and 1.6 GB size. I tried different ideas to solve this issue and eventually I found in MSFT knowledge database similar case but with IIS 7.0. My environment was built on Windows Server 2008 R2 with IIS 7.5 so ideas from this case didn’t work at all. I took only one solution from the case which decreases overall distribution time from 10 hours up to 3 hours but anyway it wasn’t acceptable by customer. Customer also opened case with PSS and they confirmed that there is a bug in the IIS 7.0 and IIS 7.5 and you need to do following:

1. For IIS 7.0 you should apply KB957001 and this KB is already included to IIS 7.5

2. You need to configure ‘maxAllowedXmlRequestLength’ attribute which specifies the maximum length, in bytes, of the request XML body for WebDAV requests. By default it’s 1000000 byte. Additional info you can find here

You can do this by running appcmd.exe command and set max length to 2Mb:

appcmd.exe set config "Default Web Site" -section:system.webServer/webdav/authoring /maxAllowedXmlRequestLength:2097152 /commit:apphost

To check that settings are applied successfully you can run following command:

appcmd list config "Site_Name_Here" -section:system.webServer/webdav/authoring

Note that this is size of XML response size and not number of files or the size of files.

As I mentioned earlier it didn’t help too much but for someone it could be good solution.

I solved this problem by wrapped up all files and folders to one EXE file with total size of 600Mb and as result decrease distribution time from 3 hours to 5 min

Миграция сетевых принтеров из Windows XP в Windows 7

В нынешнем проекте столкнулся с интересной задачей – необходимо было мигрировать все настроенные принтера из профиля пользователя из Windows XP в Windows 7. Все это надо реализовать через два сценария – refresh или in place, это когда мы проводим установку Windows 7 из Windows XP с миграцией всех пользовательских данных в SCCM State Migration Point (SMP) и второй – replace или side by side, это когда есть два компьютера: один с Windows XP и второй с Windows 7, при этом SMP не используем (идея не моя, а Заказчика, я бы сделал все через SCCM), а данные мигруем через ручной запуск USMT и все пользовательское барахло складываем на внешний винт. Далее подключаем этот винт в Windows 7 и запускаем скрипт USMT для восстановления данных. Почему был выбран ручной метод – потому что не во всех удаленных офисах Заказчика есть SCCM, а мигровать надо. Ну да ладно, мне только лучше, т.к. задачка интересная и к тому времени я ее уже решил с помощью SCCM, а теперь вот надо все это повторить в скриптованном виде.

Для решения первой задачи воспользовался статьей с Технета «When using USMT 4 in a Configuration Manager 2007 SP2 OSD Task Sequence, files are captured successfully but settings are not» http://support.microsoft.com/kb/2018593. После добавления соответствующего шага в Task Sequence, я получил требуемый результат – все принтера из пользовательского профиля успешно перекочевали в Windows 7.

Решение второй части через скрипты заняло у меня какое-то время и предыдуший совет не работал. Все мигровалось, кроме принтеров. Помощь пришла неожидано – от коллеги Alexey Semibratov’а (http://blogs.msdn.com/b/alex_semi). Я давненько почитываю его блог, но решения моей задачи там не было. Не долго думая я нашел его в майкрософтовском OCS’е и «постучался» с вопросом. Ответа он не знал, но дал очень занимательную переписку из внутреннего дистрибьюшен листа (на который я сразу же подписался), информация из которого и дала мне ключ к разгадке. Так вот, для использования USMT 4.0 с ручным запуском команд scanstate и loadstate, необходимо подготовить отдельный XML файл, я назвал его custom.xml, куда поместил следующий код:

<?xml version=”1.0″ encoding=”UTF-8″?>
<migration urlid=”http://www.microsoft.com/migration/1.0/migxmlext/miguser/NetworkPrinters”>
<component context=”UserAndSystem” type=”System” defaultSupported=”FALSE”>
<displayName _locID=”migsys.Printer”>Printer</displayName>
<role role=”Settings”>
<detects>
<detect>
<condition>MigXmlHelper.DoesOSMatch(“NT”,”*”)</condition>
</detect>
</detects>
<rules>
<destinationCleanup>
<objectSet>
<pattern type=”Registry”>HKCU\Printers\* [*]</pattern>
<pattern type=”Registry”>HKCU\software\microsoft\windows NT\currentVersion\Windows\* [*]</pattern>
</objectSet>
</destinationCleanup>
<include>
<objectSet>
<pattern type=”Registry”>HKCU\Printers\* [*]</pattern>
<pattern type=”Registry”>HKCU\Software\Microsoft\Windows NT\CurrentVersion\Devices\* [*]</pattern>
<pattern type=”Registry”>HKCU\software\microsoft\windows NT\CurrentVersion\printerPorts\* [*]</pattern>
<pattern type=”Registry”>HKCU\software\microsoft\windows NT\CurrentVersion\Windows\* [*]</pattern>
<pattern type=”Registry”>HKLM\software\microsoft\Windows NT\CurrentVersion\Print\Printers\* [*]</pattern>
<pattern type=”Registry”>HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\* [*]</pattern>
<pattern type=”Registry”>HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows NT x86\Drivers\* [*]</pattern>
<pattern type=”Registry”>HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers\* [*]</pattern>
<pattern type=”Registry”>HKLM\SYSTEM\ControlSet001\Control\Print\Printers\* [*]</pattern>
<pattern type=”Registry”>HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares\* [*]</pattern>
<pattern type=”Registry”>HKLM\SYSTEM\ControlSet001\Services\lanmanserver\Shares\* [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>
</migration>

 

Далее я запустил следующую команду на Windows XP:

scanstate.exe .\UserDataStore /o /localonly /c /efs:copyraw /all /progress:.\scanstateprogress.log /i:. \x86\migapp.xml /i:.\x86\miguser.xml /i:.\x86\custom.xml

Все данные пользователя мигранули в папку UserDataStore\USMT, в файл USMT.MIG. После этого переключил внешний винт в Windows 7 и запустил следующую команду:

loadstate.exe .\UserDataStore /c /all /progress:.\loadstateprogress.log /i:.\x86\migapp.xml /i:.\x86\miguser.xml /i:.\x86\custom.xml

Загрузился под пользовательским аккаунтом и как результат – подключенные принтера.

SCCM 2007 SP2 R2 и App-V 4.6 (x86). Проблема с доставкой виртуальных приложений

У заказчика реализовал один из сценариев интеграции App-V с SCCM – local delivery (download and execute). Все вроде шло нормально, пререквизиты для App-V 4.6 клиента и самого клиента поставил через командный файл. При попытке распространить пакет с виртуальным приложением, который содержит в себе MSI и SFT файлы, получил в логах вот такую ошибку:

The program for advertisement “P1020047” failed (“P100006C” – “Install Package”). A failure exit code of 1603 was returned.

User context: NT AUTHORITY\SYSTEM

Possible cause: Systems Management Server (SMS) determines status for each program it executes. If SMS cannot find or correlate any installation status Management Information Format (MIF) files for the program, it uses the program’s exit code to determine status. An exit code of 1603 is considered a failure.

Командная строка запуска приложения выглядит так: MSIEXEC /I package.msi /qn. Если запускаю эту же команду на клиентской машине, из под SYSTEM аккаунта, то все устанавливается без ошибок.

Неделю я бился над этой проблемой, даже открыл запрос в MSFT Premier Support (на который они кстати до сих пор не ответили!). Помогли ребята из MGSI, которые собственно и занимаются подготовкой виртуальных приложений для моего заказчика. Решение очень простое, необходимо добавит %~dp0 перед именем MSI файла и создать командный файл с этой строкой, который и необходимо запускать из пакета SCCM. Финальная строка выглядит следующим образом – MSIEXEC /I %~dp0package.msi /qn.

Согласно их утверждениям, это проблема MSI файла, который был создан через сиквенсер (sequencer). В момент когда пакет загружается в кэш клиентской машины, полный путь к SFT файлу не передается SFTMIME. Подстановка %~dp0 передает полный путь к MSI файлу.

Asset Intelligence SCCM 2007 SP2 проблема импорта не Майкрософт лицензий

На проекте столкнулся с багом в SCCM 2007 SP2 Asset Intelligence. При импорте CSV файла с данными о не Майкрософт софте происходит сбой импорта. Подробное исследование файла CSV показало, что AI в SCCM 2007 SP2 «не понимает» разницы между major и minor версиями софта и считает их дублем. Например, есть две строки в CSV файле, которые воспринимаются командой импорта (через GUI или mvlsimport.exe) как одна и та же версия:
Name,Publisher,Version,Language,Effective Quantity,PONumber,Reseller
Ad-aware 6 Personal,Lavasoft,6.0.1.181,,,,,,,,
Ad-aware 6 Personal,Lavasoft,6.0.,,,,,,,,

Тест на версии SCCM 2007 SP1 показал, что такой проблемы нет. Мой заказчик уже вплотную поработал с Microsoft Enterprise Support инженером и полученный ответ не обрадовал – это баг в AI SCCM SP2. Пока решения нет. Предложили workaround – добавлять недостающие нули, чтобы сделать поле Version уникальным. Если выйдет патч, обещали сообщить, а пока заказчик все записи с такими «дублями» вычищает из своего CSV файла.

Алерт: Agent proxying needs to be enabled

Сегодня обнаружил на сервере алерт, указывающий на то, что на RMS сервере должна быть включена опция “Allow this server to act as a proxy and discover…”

Проверка показала, что эта опция включена. Воспользовавшись постом Boris Yanushpolsky проблемный сервер удалось локализовать достаточно быстро. Запущенный командлет с GUID’ом из алерта, показал, на каком из серверов необходимо включить опцию proxy:

Get-MonitoringObject -id:’<GUID из алерта>’ | ft DisplayName

В моем случае командлет выглядел следующим образом:

И сервер оказалася один из домен контролеров. Далее последовательность действий простая – идем в консоли в Administration-Agent Managed, свойства агента, Security и там установить настройка proxy.

Проблема с SNMP traps на Windows Server 2008

Сегодня один из Заказчиков сообщил, что у него не работает мониторинг ИБП через SNMP traps на Operations Manager 2007 SP1, установленном на Windows Server 2008. Анализ ситуации показал, что у Заказчика не был установлен пакет обновления KB958936 http://support.microsoft.com/kb/958936

Всем кто столкнулся с похожей проблемой, рекомендую установить этот пакет.

Алерт: Root Management Server Unavailable

Сегодня столкнулся со следующим алертом в конфигурации Operations Manager 2007 SP1 (две виртуальные коробки: RMS+SQL на W2K3 R2 SP2):

Alert: Root Management Server Unavailable.
Source: (server name)
Path: (server name)
Last modified by: System
Last modified time: 9/7/2009 4:19:53 PM
Alert description: The root management server (Healthservice) has stopped heartbeating soon after Thu, 09 Jul 2009 2:20:29 GMT. This adversely affects all availability calculation for the entire management group.

Похожий алерт зафиксировал проблему с heartbeat’ом SQL сервера. Детальный анализ двух серверов показал, что проблема была в следующем:

1. Время между PDC эмулятором и RMS сервером “плывет”

2. Нехватка аппаратных ресурсов

Время между серверами отличалось на 8 минут, плюс владелец серверов дал обеим виртуалкам всего по 1Гб памяти. Добавление памяти и синхронизация времени решили проблему.