Георгий Григорьев

Ну так и ставьте себе ubuntu server либо debian, раз с ними уже имели дело. Если лезть в консоль совсем лениво, поставьте pfSense не Linux конечно, зато нужные функции есть из коробки и настраиваются через вебморду.

Потому что в HTML не является одиночным тегом и не может быть таковым. Подобное поведение и для других блочных тегов.

Исходя из маски, подсеть имеет диапазон
192.168.4.0-192.168.5.255
Соответственно адрес сети — 192.168.4.0, а 192.168.5.0 обычный IP подсети

Если мне не изменяет память, то значения в Windows Server по умолчанию:
1. публикация базового CRL — раз в неделю
2. публикация инкрементного CRL — раз в сутки.
Проверка сертификатов чаще всего проходит по CRL.

Начинать надо не с этого:

1. Сделайте список вашей инфраструктуры. что вы хотите мониторить прямо сейчас, что хотите мониторить потом. Подумайте не только о серверах, но и о сетевом оборудовании, системах электропитания (UPS), телефонии и т.д.

Если хотите работать чисто по SNMP, то можно обойтись zabbix, но имейте ввиду, что многие сенсоры надо будет добавлять в шаблоны. Например, шаблоны под Hewlett-Packard Proliant в zabbix содержат меньше контрольных значений, чем их возвращает check_hpasm (об этом плагине писалось здесь).

Для nagios/icinga/shinken есть масса плагинов ( смотреть поддерживаемое оборудование и сервисы здесь — exchange.nagios.org/directory/Plugins и здесь — www.monitoringexchange.org/inventory/Check-Plugins ).

особняком стоит zenoss — все его плагины собраны в Zenpack-и, написанные на питоне, но он поддерживает и плагины nagios.

2. На скольких площадках стоит оборудование? Есть ли (или потребуется в будущем) распределенный мониторинг?
Об этом надо подумать особо, чтобы в дальнейшем спокойно расширить систему мониторинга, а не менять ее на какую-то другую.

Если каналы между площадками жирные (хотя бы 100 Мбит) — можно поставить что угодно.
Если каналы узкие — 1-2Мбит, да еще и ADSL, то ставьте nagios/icinga/shinken. Zabbix — товарищ, который любит толстые каналы, а вот icinga экономно их пользует, кроме того shinken изначально затачивался для работы в распределенных системах

После того, как со всем этим определились, тогда уже можно будет выбирать, что же вам нужно.

Собирать в nagios/icinga/shinken информацию с серверов можно четырьмя путями

1. Через агент NSClient++ (NRPE запросы)
2. Без агента — Через поднятую SNMP-службу
3, Без агента — Через WMI (если сервер работает под Windows 2003/2008)
4. Без агента — Информацию о состоянии самого железа можно получать через управляющие интерфейсы серверов (HP iLO, IBM RSA, Dell DRAC и т.д.)

Как то так:

          UPDATE table1 SET  
          field1 = CASE WHEN ISNULL(i.field1,'')='' THEN t.field1 ELSE i.field1 END
          FROM table1 t INNER JOIN inserted i on t.ID=i.ID
          
          INSERT INTO table1 (ID,field1) 
          SELECT ID,field1 FROM inserted i WHERE NOT EXISTS (SELECT TOP 1 ID FROM table1 t WHERE  t.id = i.id)