Пожалуй, выложу кусок своего скрипта, предназначенного для быстрого создания учетных записей пользователей со стандартными настройками и паролями. Думаю, из имен переменных понятно, какая за что отвечает.
Этому блоку предшествует графическая форма, куда вносится ФИО пользователя, его e-mail и номер заявки на прием нового сотрудника по системе Service Desk, который пишется в поле description, дабы не искать потом долго и мучительно, кто и на каком основании создавал учетную запись. ФИО, введенное на русском языке, парсится и транслитеруется для генерации логина, соответствующего корпоративному стандарту.
Также через ListBox выбирается филиал, в котором будет работать пользователь — от этого зависит переменная $org, отвечающая за OU, где будет создана учетка, и переменные $HomeDirectory и $DocsDrive, где в зависимости от филиала меняется имя файлового сервера — хранилища перемещаемых профилей.
Таким образом, для создания учетки со всеми принятыми в компании стандартными настройками в нужной OU достаточно скопировать три поля из заявки в системе Service Desk.
Если будет интерес — могу как-нибудь выложить и описать скрипт целиком.
Могу вам сказать на своем опыте, что двигаетесь вы в абсолютно правильном направлении. Я тоже очень многие вещи изучал самостоятельно, не извлекая из этого прибыли, зато это позволило мне получить ту работу, которую я хотел.
Если быть совсем точным, то в оригинале это звучало так: «при ста процентах прибыли, капитал попирает все существующие законы, а при трехстах нет такого преступления, на которое он бы не решился, хотя бы под страхом виселицы».
В Москве раньше была Служба спасения на гражданском CB диапазоне. Через них можно было вызвать экстренные службы… если докричишься до диспетчера. Это ведь не телефон, слабый сигнал переносной рации могут не услышать. Жива ли эта служба сейчас — не знаю. Чтобы связаться с полицией, нужна радиостанция совсем другого диапазона, и вы правы — в обычное время за такое по головке не погладят. А в случае ЧС — если докричитесь, то, полагаю, ответят. Но надо еще знать как, кого и на какой частоте вызывать — не все там так просто, как кажется.
Не подскажете ли навскидку, по какой именно радиостанции (диапазон, характеристики, пример конкретной модели) и на каких частотах простой гражданин, проживающий в Москве, может связаться с МЧС так же гарантированно, как и набрав 01 с городского телефона или 112 с мобильного? В случае, если из-за отключения света гавкнется телефония по оптике, а GSM сети будут перегружены?
Насколько помню законодательство, все эти «отключим телефон» — не более чем пустые угрозы, ибо при вашем отказе от оптики они обязаны продолжать предоставлять услугу по меди до тех пор, пока для этого существует техническая возможность.
На моей старой работе зам. ИТ директора — к слову, отличный IT-инженер и просто хороший человек — не имел высшего образования. Не вижу в этом ничего плохого.
Врать не буду, но Skype насколько помню имеет свой API, через который можно взаимодействовать с клиентом. Я бы посмотрел в этом направлении. По крайней мере, siptosis работал именно так.
Вот вас все минусуют, а я соглашусь в этом именно пункте. Я ни разу не руководитель и не стремлюсь к этому, но я прекрасно помню свои впечатления от совместной работы с совершенно некомпетентным альтернативно одаренным товарищем, которого держало на работе доброе руководство, потому что «жалко увольнять, у него же ребенок маленький». Причем люли от вышестоящего руководства, полученные прямым руководством за его косяки, тоже ничему не учили.
Я бы еще добавил пункт «старайтесь максимально стандартизировать и автоматизировать все действия — разумеется, не в ущерб продуктивности». Вот вам пример.
Когда-то я работал эникеем в автомобильном дилерском центре. Там было очень много специфических ноутбуков (как правило, Panasonic Toughbook CF-серии) с кучей хитрого марочного софта, использовавшихся для диагностики или прошивки автомобилей. Критичными были не хранящиеся на них данные сами по себе, а именно этот самый марочный софт, который настраивался очень долго, очень муторно и с непредсказуемыми последствиями, отказ же софта означал задержки в ремонте автомобилей.
Я внедрил систему сетевого восстановления через PXE, при которой пользователю при отказе диагностического ноута было достаточно просто загрузить его по сети и нажать одну кнопку, после чего туда автоматически разворачивался бэкап образа ОС именно этого ноута. Зачастую это оказывалось быстрее, чем поиск проблемы и ее решение силами IT, ибо поддержка производителя для такого софта либо отсутствовала вовсе, либо была очень медленной. Бэкапы, разумеется, периодически обновлялись. А поскольку актуальность данных особой роли не играла, а важна была только корректно настроенная и работающая свежая версия марочного софта, то бэкапы делались как раз при обновлении этого самого софта.
После внедрения этой системы я забыл про «задерживаться на работе, потому что надо срочно!!!111 починить ушатанный диагностический ноут».
Я полностью с вами согласен, жаль, плюсануть не могу. Из эникеев можно расти очень много куда. Я стал инфраструктурным админом, многие коллеги по прежним местам работы — кто в сетевики подался, кто в 1С, кто в интеграцию, а кто-то вообще в SAP/кодинг. Одна моя знакомая вывела следующую формулу: «Эникейщиков не бывает. Бывают вечные эникейщики и бывают админы, которые на данный момент имеют мало опыта».
Не всем дано и не все хотят быть IT директорами. Хотя это и не освобождает от необходимости следования упомянутым здесь рекомендациям и элементарному здравому смыслу. Я, например, плохо умею общаться с твердолобым не-IT руководством и доказывать что-то идиотам, посему перспектива стать руководителем меня не прельщает. Гораздо больше по душе мне решать чисто технические задачи развития и поддержки инфраструктуры. Поэтому я работаю в крупной организации, общаясь по насущным вопросам со своим IT руководством, которое прекрасно понимает все без объяснений «на пальцах».
Присоединюсь. Работал я в такой конторе, правда, недолго. При этом не в одиночку — был там отдел IT, был руководитель IT… Пофиг. «Работает же оно как-то, и ладно, мы лучше потратим бабло на продвижение сайтов компании». Даже суточный простой из-за вполне прогнозируемого сбоя ничему их не научил.
Это вы, батенька, не админили в территориально распределенной, да еще и растущей, конторе с большим количеством внутренних проектов. «Настроил и делай апдейты»? То внедрение нового сервиса, то расширение текущих, то разворачивание инфраструктуры для новых филиалов…
Этому блоку предшествует графическая форма, куда вносится ФИО пользователя, его e-mail и номер заявки на прием нового сотрудника по системе Service Desk, который пишется в поле description, дабы не искать потом долго и мучительно, кто и на каком основании создавал учетную запись. ФИО, введенное на русском языке, парсится и транслитеруется для генерации логина, соответствующего корпоративному стандарту.
Также через ListBox выбирается филиал, в котором будет работать пользователь — от этого зависит переменная $org, отвечающая за OU, где будет создана учетка, и переменные $HomeDirectory и $DocsDrive, где в зависимости от филиала меняется имя файлового сервера — хранилища перемещаемых профилей.
Таким образом, для создания учетки со всеми принятыми в компании стандартными настройками в нужной OU достаточно скопировать три поля из заявки в системе Service Desk.
Если будет интерес — могу как-нибудь выложить и описать скрипт целиком.
Когда-то я работал эникеем в автомобильном дилерском центре. Там было очень много специфических ноутбуков (как правило, Panasonic Toughbook CF-серии) с кучей хитрого марочного софта, использовавшихся для диагностики или прошивки автомобилей. Критичными были не хранящиеся на них данные сами по себе, а именно этот самый марочный софт, который настраивался очень долго, очень муторно и с непредсказуемыми последствиями, отказ же софта означал задержки в ремонте автомобилей.
Я внедрил систему сетевого восстановления через PXE, при которой пользователю при отказе диагностического ноута было достаточно просто загрузить его по сети и нажать одну кнопку, после чего туда автоматически разворачивался бэкап образа ОС именно этого ноута. Зачастую это оказывалось быстрее, чем поиск проблемы и ее решение силами IT, ибо поддержка производителя для такого софта либо отсутствовала вовсе, либо была очень медленной. Бэкапы, разумеется, периодически обновлялись. А поскольку актуальность данных особой роли не играла, а важна была только корректно настроенная и работающая свежая версия марочного софта, то бэкапы делались как раз при обновлении этого самого софта.
После внедрения этой системы я забыл про «задерживаться на работе, потому что надо срочно!!!111 починить ушатанный диагностический ноут».