Включение Мегафон модема на Hipad под ОС Android

Сегодня попал в руки Hipad с 800Mhz-овым процессором под управлением Android 2.3, стояла задача поскольку в аппарате нет 3G модема, стояла задача запустить интернет на нем через Мегафон 3G модем.

Всё оказалось достаточно не сложно по ссылке:

http://ameth.ru/page/howto-plug-3g-modem-huawei-e150

благо под рукой было всё необходимое.

Использовали настройки для Internet-GPRS, а не WAP-GPRS со страницы:

http://moscow.megafon.ru/publications/rychnye_nastrojoki_telefonov.html

Пользователь аппарата был им доволен - производительностью и возможностью, хотя батареи при использовании игр и WiFi хватало на 6 часов.

Интересно - Невозможно сделать клон работающего контроллера домена Active Directory на ESX.

Недавно при подготовке тестового стенда столкнулся с невозможностью сделать клон контроллера домена, выдавалась ошибка:

Cannot create a quiesced snapshot because the snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine

а как оказалось в дальнейшем и снапшот. Контроллер домена уже давно был виртуальным. При выяснении этой проблемы с технической поддержкой VmWare, оказалось что действительно есть такая проблема, но она по большей части на стороне Windows(была Windows 2008 R2). Проблема не связана с Volume Shadow Provider и его WMI writers.
Узнать состояние Writer-ов зарегистрированных в системе можно командой

vssadmin list writers

Дело в том, что база Active Directory, расположенная в файле .dit подвержена постоянной нагрузкам по чтению записи и интервал времени необходимый для снятия образа превышает допустимый тайм аут в течении которого в базу .dit не может быть слит лог файл этой базы. В моем случае ошибка выпадала после 10 минут клонирования.

Ссылки по теме:
(причина):
http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2virtualization/thread/2e913d5c-899b-46b2-88a2-a7bf7a0a584d

(методы борьбы):
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1018194

Прожорливые SAVFMSESp.exe процессы и их оптимизация

После миграции сервера MS Exchanage 2007 с ролью Hub Transport с физического сервера на виртуальный, решили что ему не нужно много памяти - 6Гб, и отдали только 4. После нескольких дней работы , зайдя на него увидел что сервер находиться в жутком свопе, что реально он затребовал более 5Гб оперативной памяти при наличии 4Гб физической оперативной памяти, а это значит, что интенсивный обмен с диском и менее эффективная работа служб.

В TaskManger-е оказалось 9 процессов SAVFMSESp.exe относящихся к Symantec Mail Security for Microfoft Exchange, кадый из которых был не менее 60Мб, а самый прожорливый около 260Мб, суммарно они отъедали более 1Гб памяти что было весьма печально.

Поиск в интернете привел к статье:

http://www.symantec.com/business/support/index?page=content&id=TECH84498&locale=en_US

Используя которую поменял параметры и получил всё равно более 4Гб используемой оперативной памяти, ну тут пришлось просто выдать виртуалке ещё один Гб, итого стало 5Г. физической виртуальной памяти, пока полет нормальный.

Боремся с Deadlock на Net.Framework - не работает WSUS

После установки очередного обновления на сервере, который сам и является WSUS(Windows Software Update Service) сервером, и перезагрузки его не мог никак зайти в консоль WSUS - она постоянно выпадала, не помогало даже удаление файла wsus в папке %appdata%\Microsoft\MMC\.

Поиск по ошибке вида:

ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

а также в application логе:

Event Type: Warning
Event Source: W3SVC-WP
Event Category: None
Event ID: 2262
Date: 22.07.2011
Time: 10:49:40
User: N/A
Computer: WSUS-REAL
Description:
ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Поиск в интернете всё время приводил к одной и той же статье:

http://support.microsoft.com/kb/974165/en-us
По которой не ясно было что делать, по крайней мере для меня.

Всё говорило о том что "съехала крыша" у Net.Framework, поскольку базу WSUS(SUSDB), расположенную на SQL кластере переводил в offline, а затем в online с отключением пользователей. Эти манипуляции с базой ни привели ни к чему.

На сервере были установлены следующие версии Net.Framework: 2.0, 3.0, 3.5 со всем обновлениями

Так как WSUS перестал работать после установки последних обновлений и перезагрузки, решил откатить последнее обновление, KB2478658 для Net.Framework 2.0 и 3.5 и через "Установка и Удаление Программ" исправил установку Net.Framework 3.5. После перезапуска Windows(на всякий случай) WSUS заработал нормально.

Кстати, после этого я установил обновление KB2478658 и перезагрузил контрольно сервер - WSUS всё-равно работал нормально, просто какой то глюк с Net.Framework.