Записки IT специалиста

7 июля в 20:00: балансировка трафика ЦОД. Научитесь балансировать трафик в ЦОД и корпоративных сетях. Регистрируйтесь! Узнать больше #реклама 16+ otus.ru О рекламодателе

Защита RDP от перебора паролей при помощи оборудования Mikrotik Атака с полным перебором паролей (брутфорс) - одна из наиболее часто встречающихся угроз в современном интернете. Она базируется не на уязвимостях ПО, а на нарушении политики паролей, что иногда оказывается гораздо более продуктивным. Пользователи не любят сложных паролей и даже когда есть явные требования по сложности стремятся использовать более простые комбинации, либо словарные слова. Многие также используют одну пару логин - пароль для всех учетных записей и при компрометации одной из них эти данные могут попасть в руки злоумышленников. Одним из наиболее часто атакуемых сервисов является RDP и сегодня мы посмотрим, как можно его защитить. ✅ Читать далее: https://interface31.ru/post/zashhita-rdp-ot-perebora-paroley-pri-pomoshhi-obrudovaniya-mikrotik/

Защита RDP от перебора паролей при помощи оборудования Mikrotik Атака с полным перебором паролей (брутфорс) - одна из наиболее часто встречающихся угроз в современном интернете. Она базируется не на уязвимостях ПО, а на нарушении политики паролей, что иногда оказывается гораздо более продуктивным. Пользователи не любят сложных паролей и даже когда есть явные требования по сложности стремятся использовать более простые комбинации, либо словарные слова. Многие также используют одну пару логин - пароль для всех учетных записей и при компрометации одной из них эти данные могут попасть в руки злоумышленников. Одним из наиболее часто атакуемых сервисов является RDP и сегодня мы посмотрим, как можно его защитить. ✅ Читать далее: https://interface31.ru/post/zashhita-rdp-ot-perebora-paroley-pri-pomoshhi-obrudovaniya-mikrotik/

vPC (MLAG) и VxLAN/EVPN: как балансировать трафик в ЦОД. Пошаговый разбор балансировки: от основ до нюансов VxLAN/EVPN и vPC. Научитесь выявлять узкие места и подбирать режимы, чтобы избежать сбоев. Регистрируйтесь - напомним о старте! 7 июля в 20:00. Узнать больше #реклама 16+ otus.ru О рекламодателе

Не включается сетевое обнаружение в Windows / Windows Server Современные ОС предусматривают современные подходы ко многим привычным вещам, отказываясь от многих устаревших технологий. С одной стороны это правильно, с другой - может вызвать и вызывает проблемы в переходный период. Поэтому системный администратор всегда должен интересоваться всеми нововведениями используемых систем, а также уметь применять их на практике. Здоровый консерватизм - это хорошо, но он не должен препятствовать прогрессу. Сегодня мы поговорим об одной часто встречающейся проблеме - не включается сетевое обнаружение в последних версиях Windows 10/11 и Windows Server. ✅ Читать: https://interface31.ru/post/ne-vklyuchaetsya-setevoe-obnaruzhenie-v-windows-10-windows-server/

Yandex Ecom Open Air — летнее событие про онлайн-продажи Yandex Ecom Open Air 2026 объединяет деловую программу, живое общение и атмосферу фестиваля в одном потоке. Здесь обсуждают технологии, которые становятся частью среды. Исследуют силы, которые влияют на весь рынок. Находят новые связи, идеи и точки роста. В течение дня пространство фестиваля наполняют выступления, дискуссии, встречи, специальные форматы, музыка и активности партнёров. Присоединиться к происходящему можно из любой точки — на площадке фестиваля или через онлайн-трансляцию. Зарегистрироваться #реклама 18+ ecomfest.ru О рекламодателе

Листая старую тетрадь... У многих коллег, особенно молодого поколения, бытует мнение, что Windows всегда была дружелюбной администратору системой, где все вопросы решались на уровне "подключи и работай" и "далее - далее - готово". А Linux, особенно тех лет, это треш, ад, красные глаза и пляски с бубнами. Но не тут-то было. Дружелюбным Windows был не всегда. Выше представлен скриншот из NT 4, которая вполне себе успешно жила в отдельных местах вплоть до середины нулевых. Если вы найдете там диспетчер устройств и другие простые инструменты администрирования, то значит это не NT4. А уж чего стоило добавить туда новую железку, да чтобы она еще и работала. Приключений, иногда, хватало на полдня и полночи. А сейчас даже в Linux - максимум собрать модуль ядра. Скучно...

📑 От метрик к прогнозированию: как бизнес и ИИ меняют мониторинг Сегодня мониторинг — больше чем техническая задача. Этот инструмент напрямую влияет на успех бизнеса. Но как не потеряться в потоке данных и предсказать сбои до их появления? Приглашаем на вебинар, где ответим на этот вопрос и покажем, как выглядит новый стандарт наблюдаемости. 📅 9 июля | 11:00 (по Мск) В программе вебинара

⏺ Эволюция инструментов: расскажем, почему старые подходы не работают и как выбрать современное решение. ⏺ Бизнес-драйверы: обсудим, как бизнес-задачи определяют тренды развития мониторинга. ⏺ Эпоха ИИ: покажем, как ИИ помогает автоматизировать процессы и анализировать данные. ⏺ «Астра Мониторинг»: продемонстрируем решение, которое позволяет не просто видеть, а предвидеть.

Приходите, чтобы узнать, как сделать ваши ИТ-системы прозрачными, управляемыми и надежными. 🔗 Зарегистрироваться на вебинар

Синие экраны смерти   Синий экран смерти, он же BSOD знаком каждому пользователю Windows, но не все знакомы с его историй и эволюцией, которая весьма интересна.   Начнем мы совсем издалека, с MS DOS, которая могла зависать и для которой в клавиатурный код IBM PC была зашита комбинация Ctrl+Alt+Del, которая выполняла перезагрузку компьютера.   Windows 3.1 являясь гибридной системой на основе MS DOS могла запускать старые 16-битные приложения DOS в полноэкранном режиме, и они также могли зависать, чтобы снять зависшее приложение нужно было также нажать Ctrl+Alt+Del.   Но теперь это не приводило к перезагрузке ПК и у пользователя появлялся выбор действий. Чтобы пояснить ему этот выбор и был создан специальный экран. Официально он назывался System Close Sign-off Screen (Экран подтверждения закрытия системы) и был черным.   В синий цвет его перекрасил Стив Балмер, которому не понравился сложный текст, который написали программисты, и он сам переписал его, заодно изменив цвет на синий, чтобы он отличался от простых DOS-окон и сообщений.  Но по факту это не был BSOD, а просто диалоговое окно.   После выхода Windows 95, которая хоть и являлась полноценной 32-разрядной ОС, но также базировалась на DOS и не имела жесткой изоляции памяти. Приложения и драйвера часто лезли в чужие участки памяти, что приводило к фатальным ошибкам.   Для перехвата этих событий другой разработчик Раймонд Чен написал экран перехвата, который позволял завершить сбойный процесс и продолжить работу системы без перезагрузки, который официально назывался Fatal Exception Screen (Экран фатального исключения).   На самом деле помогало это мало и Windows 9.x при любом сбое рассыпалась как карточный домик и у многих именно этот синий экран стал ассоциироваться с фатальными ошибками системы.   Третий экран был разработан Джоном Вертом для Windows NT 3.1, которая исповедовала совсем иной подход, согласно которому система с фатальным сбоем в ядре или драйвере должна быть остановлена и перезагружена. А чтобы администратор мог понять, что произошло он разработал специальный диагностический экран Bug Check Screen (экран проверки ошибок). На этот экран выводился стоп-код, список загруженных драйверов и шестнадцатеричные значения адресов для отладки.   Синий цвет был выбран исходя из соображений лучшей читабельности на мониторах тех лет (монохромных и цветных). При этом из-за обилия информации такой экран оказывал пугающее воздействие на обычных пользователей, но был бесценным кладезем информации для администраторов.   По сути, именно это был первый настоящий «синий экран смерти», так как никаких альтернатив, кроме перезагрузки системы он не оставлял, но такого термина пока еще не было.   Windows NT оказалась очень стабильной системой, но не имела широкого распространения, оставаясь ОС для сетей и профессионалов, а вот линейка Windows 9x широко пошла в народ, при этом не отличаясь особой стабильностью и именно синий экран Чена стал тем самым «синим окном смерти».   Термин оказался настолько удачным, что сразу ушел в народ, а оттуда перекочевал в официальную документацию и с тех пор все подобные окна Windows именовались как BSOD (Blue Screen of Death).   Начиная с Windows 2000 синий экран Верта сделали немного лаконичнее, оставив только код ошибки, имя сбойного драйвера или библиотеки и ее адреса в памяти, чтобы не пугать и не запутывать пользователей, а кому надо – те посмотрят все это в дампе.   Ну а после выхода Windows XP, объединившего домашнюю и корпоративную ветви ОС Windows у нас остался только синий экран Верта, тот самый, который «настоящий». И он практически в неизменном виде дожил до наших дней.   В Windows 8 ему сделали редизайн, сделав его более стильным и дружелюбным, с грустным смайликом. А в Windows 10 добавили на него QR-код со ссылкой на статью документации по приведенному на экране коду ошибки. Но это уже совсем другая история…

Если вы держите инфраструктуру, то видели это сами: ИИ-фича редко падает от слабого железа. Куда чаще её роняет то, что не заложили в эксплуатацию — перегрев и троттлинг в закрытом корпусе, отвал на узком канале, дрейф модели после смены данных. morana.log ведут инженеры MoranaLabs (R&D прикладного ИИ). Разбираем публичные факапы ИИ по косточкам: что сломалось на инженерном уровне и во сколько обошлось. Edge против облака без догм, честный TCO, регуляторика РФ. Памятка из практики — пять вопросов, которые топят ИИ-пилот, если не задать их до договора: https://t.me/moranalog/41?erid=2W5zFGdg2Eu Без хайпа и «топ-5 нейросетей». Если трогаете ИИ в проде — загляните: https://t.me/+DoDSJkWd4nI2MzEy?erid=2W5zFGdg2Eu

Раскрыты эксплоиты для 23 неисправленных уязвимостей в FFmpeg, VLC, Firefox, Docker, PHP, OpenVPN, nmap, libssh2, nghttp2 и 7zip

Анонимный исследователь безопасности опубликовал в открытом доступе прототипы 23 эксплоитов, в которых задействованы ещё не исправленные (0-day) уязвимости в таких проектах, как FFmpeg, VLC, Firefox, Docker, PHP, OpenVPN, nmap, libssh2, nghttp2, 7zip, Ghidra, Gitea, c-ares, Floci, Flowise, ImageMagick, Lunar Client, MyBB, objdump и RustDesk. Уязвимости были выявлены в результате fuzzing-тестирования проектов с привлечением AI-модели GPT-5.5-3-Codex-Spark. Утверждается, что эксплоиты, за исключением эксплоита к RustDesk, были написаны вручную, но вся сопроводительная документация к ним сгенерирована через AI.

✅ Отсюда: https://www.opennet.ru/opennews/art.shtml?num=65794 В этой новости все прекрасно – это новая реальность, с которой мы столкнулись после прихода в нашу жизнь ИИ. Его можно не замечать, можно игнорировать, можно считать переоцененным, но по факту он есть, и он работает. А в какую сторону он будет работать – это уже от применяющего его зависит, это как топором: можно дров наколоть, а можно бабку-процентщицу зарубить. И это не единичный случай, ИИ старательно ищет и находит уязвимости там, где люди не видели их годами и будет продолжать это делать. В долгую это кардинально изменит модель разработки, когда ИИ будет, как минимум, проверять написанный код. А вот на короткой дистанции легко не будет никому, ни разработчикам, ни пользователям. И, возможно, рынок ПО существенным образом изменится, те продукты, которые не смогут поддерживать подобный темп исправлений вынужденно уйдут на обочину. Пользователям же придется серьезно пересмотреть модель обновлений в частном и использование софта в общем. Здесь как раз на первый план будет выходить скорость доставки обновлений и их атомарность, чтобы можно было обновить/откатить единственный пакет, а не все состояние системы. Кроме того, это прекрасная иллюстрация качества кода, написанного руками, который часто пытаются противопоставить коду, написанному ИИ. Хотя ничего удивительного в этом нет – людям свойственно ошибаться, это нормально. И также нет ничего удивительного, что ИИ пишет код гораздо лучше среднего человека, как минимум соблюдая все правила и соглашения языка и не ленясь делать проверки. Также будущее за безопасными языками, тем же Rust, хотя его и модно ругать. Но это будет уже совсем другая история и совсем другой рынок ПО, который мы с нынешним темпом развития технологий можем увидеть уже в самом ближайшем будущем.

Как управлять Windows, Linux и macOS из единого окна? 2 июля в 11:00 Мск команда Ринго проведет онлайн-вебинар «Ринго 3.0: от MDM к Unified Endpoint Management». Если вы управляете корпоративными устройствами, отвечаете за поддержку рабочих мест или ищете замену зарубежным MDM/UEM-решениям — этот вебинар для вас. На вебинаре покажем, как: ✅ централизованно управлять устройствами на Linux, Windows, macOS и iOS из единой консоли; ✅ сократить количество инструментов для администрирования; ✅ автоматизировать подготовку и обслуживание рабочих мест. В программе — живое демо системы, реальные сценарии использования и ответы на вопросы. Кому будет полезно: • системным администраторам; • ИТ- и ИБ-директорам; • ответственным за импортозамещение ИТ-инфраструктуры. После вебинара вы сможете получить доступ к тестированию Ринго с персональным сопровождением. 📅 2 июля, 11:00 Мск 💻 Участие бесплатное 👉 Зарегистрироваться #реклама О рекламодателе

Про бумажки Как известно, чем больше бумаги – тем чище одно место. И в обсуждениях этот метод неоднократно всплывал. Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность? Скажем сразу – надежный и проверенный способ только один – не работать с чудаками на букву «м». Поэтому если заказчик или работодатель начинает неоднократно исполнять дичь, что с ним лучше расстаться по-хорошему, чем потом выяснять кто прав, а кто виноват. Способ обложиться служебками не так прост, как кажется, и таит свои подводные камни. Прежде всего, служебку надо подать по всем принятым правилам документооборота, регистрацией и отметкой на своем экземпляре. Иначе толку от такой служебки не будет, она тут же отправится в мусорку. В этом плане внешним подрядчикам проще, у них в договоре указаны допустимые форматы обмена документами и в большинстве случаев достаточно обычного письма по электронной почте. Более важные документы можно всегда отправить по ЭДО или заказным письмом с уведомлением. Но вернемся к нашим баранам. А именно служебкам, в некоторых случаях их наличие может сыграть резко против вас, вплоть до самых печальных последствий. Почему так? Начнем немного издалека. Для чего пишется служебка? Для того чтобы переложить ответственность с себя на руководителя, который не выделяет нужных ресурсов. Мол я тебя уведомил, моя совесть чиста, теперь это твоя проблема. А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс. Скажем пришла проверка на пиратство, а вы неоднократно служебками уведомляли руководство о наличии нелицензионного ПО. Вы молодец? Нет, вы только что подняли статью с пола. Потому что следователь так и запишет: осознавая противоправность деяния, группой лиц, по предварительному сговору… Если касаться бюджетки, то там список статей куда более широкий, включая коррупционные и всякие прочие, касающиеся той же КИИ. И там наличие служебки будет являться доказательством того, что вы были в курсе всех творящихся безобразий, но мер по их предотвращению не приняли, в ближайший околоток с заявлением не обратились, а следовательно, пойдете прицепом. Поэтому перед тем, как руки потянулись писать служебку, надо сесть и крепко подумать, а что скажет прокурор, попади эта бумага ему в руки? Иногда проще пройти за недалекого и недостаточно квалифицированного товарища, чем поднять с пола статью. Но это только одна сторона монеты. На другой стороне коммерческие структуры и бизнес. А бизнес бывает разный. Вы можете обложиться служебками в два слоя, но если владелец бизнеса решит, что вы крайний – то крайним назначат именно вас. И подпрыгивать там бесполезно. Свободно улетите по статье, если сами не уйдете по собственному, а там можете пытаться в суде доказать свое честное имя и восстановиться. Но, это в реальной жизни практически волчий билет. Так как ваш новый потенциальный работодатель видит, что вы не смогли уладить конфликт полюбовно (т.е. уйти по собственному), а значит вы человек конфликтный. А судебная тяжба говорит о том, что вы еще и сутяжник. Ну и нафиг ему такой сотрудник? Но это мы про бизнес цивилизованный, а кроме бизнеса цивилизованного, у нас осталось немало бизнеса дикого, который так и живет «по понятиям». И по этим самым «понятиям» вы будете им должны. Полиция? С тем некомплектом, который творится там будет классическое: когда убьют – тогда и приходите. И даже если наш герой имеет стальные тестикулы, то всегда есть слабое звено: жена, дети, родители. А еще никто не исключает связи вашего бывшего работодателя в силовых структурах, когда прессовать вас будет уже полиция. И тут надо или иметь контрсвязи, или сидеть и не отсвечивать. Все это наша жизнь и реалии на земле. Поэтому служебки это хорошо, но абсолютно бесполезно во многих случаях. Поэтому – просто не работайте с чудаками на букву «м».

Как повысить эффективность товарных операций с 1С:WMS Ошибки комплектации, пересортица, ручные операции и отсутствие актуальных данных по остаткам напрямую влияют на скорость отгрузки и прибыль компании. 1С:WMS позволяет выстроить прозрачное управление складом: автоматизировать приемку, размещение, отбор, инвентаризацию и контроль работы персонала в единой системе. ГК «Автомакон» внедряет 1С на складах дистрибьюторов, производственных предприятий и ритейла. Автомакон не просто запускает систему, а адаптируем процессы под задачи бизнеса и интегрируем WMS с корпоративными ИТ-системами и оборудованием. Результат внедрения: • сокращение складских ошибок; • ускорение обработки заказов; • контроль складских операций в режиме реального времени. Хотите узнать, как устранить ошибки и простои на складе Получить консультацию #реклама 16+ wms.automacon.ru О рекламодателе

Очередная сказка о потерянном времени Где-то примерно год назад внедряли одному заказчику систему для управления ИТ-отделом. Заказчик был рад и счастлив, строил обширные планы и уже готовил разнообразные интеграции. Недавно встретились, просил как там его управление ИТ-отделом поживает? Выяснилось, что никак, задвинуто на самую дальнюю виртуалку самого дальнего сервера. Потому что оказалось никому не нужно, в том числе самому ИТ-отделу. Надо сказать, что такому исходу мы совершенно не удивились, а точнее ожидали чего-то подобного с самого начала. Потому что подобных историй мы видели ни одну и не две. Все это хорошо и красиво смотрится на бумаге, в мечтах и презентациях. Вот как внедрим, вот как заживем! А на самом деле это просто дополнительная нагрузка на персонал, дополнительная работа и дополнительная бюрократия. И если система не решает никаких насущных проблем – то заканчивается всегда примерно одинаково. У нас уже примерно сформирован собственный рейтинг «ненужности», который выглядит следующим образом: 1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно. Причина проста – такой базой знаний должен кто-то заниматься, причем заниматься постоянно. Если этого нет, то база утрачивает актуальность и ей просто перестают пользоваться, а если перестают пользоваться, то какой смысл ее пополнять. Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает. 2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п. Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным. Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются. 3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству. А по факту получаем кучу метрик, не меньше алертов, которые приходят по делу и без дела и необходимость серьезно вникать и настраивать продукт. После чего тот же условный Zabbix задвигается на самый дальний сервер и благополучно забывается. 4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги. Но чтобы у вас работала система учета заявок, у вас уже должна быть работа с заявками или осознанная необходимость и политическая воля в ее создании и внедрении. Потому как инструмент выбирается для решения задачи, а не наоборот. Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить. Если нет системы работы с заявками, равно как и самой культуры такой работы, то данный сервис окажется бесполезен и поигравшись месяц другой о нем все забудут. 👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня? И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.

🎙 Голос → текст за минуту. Без ручной расшифровки звонков и видеовстреч. Если вы тестируете AI-сервисы и стремитесь автоматизировать рутину — вот интересный кейс. 1С-Рарус:ЭХО — сервис распознавания речи с точностью до 96%, который: ✅ переводит аудио и видео в текст ✅ разделяет спикеров по голосам ✅ форматирует текст и помогает работать с ним (в т.ч. в режиме диалога) ✅ понимает >10 языков(и можем подключить еще >80) ✅ доступен в Telegram, MAX, 1С и через API для своих решений Подходит для: ➖протоколов встреч ➖личных голосовых заметок ➖расшифровки звонков ➖разборов интервью и подкастов 🎁 Есть бесплатный тариф — до 1 000 минут в месяц для команды. 👉 Попробовать бесплатно прямо в Telegram #реклама О рекламодателе

Практическое использование программных лицензий 1С:Предпритие Данный материал написан на злободневную тему, так как не все умеют правильно использовать желтый листок с набором цифр. Что представляет собой программная лицензия? Это листок (физический или электронный), на котором нас интересуют два набора цифр. В самом верху крупно напечатан рег. номер – это десять цифр, являющихся уникальным идентификатором лицензии. Его будут спрашивать при всех обращениях в поддержку и к нему привязываются все перечисленные ниже коды. Пинкоды, напечатаны мельче в нижней части листка, напечатаны с избытком, например, на лицензии на 5 рабочих мест указано: пинкодов 8, из них 3 резервных. Каждый пинкод дает вам право на получение или восстановление лицензии. Получение лицензии подразумевает ее установку на новое рабочее место, здесь мы просто указываем пинкод и заполняем данные о пользователе. После активации лицензии пинкод будет помечен как активный. Остальные останутся свободными/резервными. До определенного момента никакой разницы между свободными и резервными пинкодами нет, вы можете использовать любой пинкод с листа как для активации новой лицензии, так и для восстановления уже существующей. При восстановлении лицензии мы указываем старый пинкод и новый пинкод. После восстановления старый пинкод становится заблокированным. После того, как количество активных лицензий сравняется с количеством доступных по данной лицензии, то все остальные пинкоды станут резервными, т.е. использовать их можно только для восстановления уже существующих лицензий. Получить новую лицензию по такому номеру не получится. Вот с этим моментом и связан ряд тонкостей. Разберем несколько случаев. Во всех случаях будем рассматривать набор лицензии на 5 рабочих мест: пинкодов 8, из них 3 резервных. Изначально мы установили лицензии на три рабочих места, потом на двух поменяли оборудование. А вот дальше возможны варианты. 1️⃣ Администратор решил не заморачиваться и на новые ПК получил новые лицензии. Теперь у нас 5 активных лицензий, 1С не отслеживает статус лицензии онлайн/оффлайн. И далее новые лицензии мы уже активировать не сможем. Теперь нам доступен только один путь – восстановление. На новом ПК нам нужно будет указать пинкод от старого и те данные пользователя, которые были указаны при первом получении лицензии. 2️⃣ Администратор не поленился и восстановил лицензии на новые ПК, теперь у нас два пинкода заблокировано, три активно, а из оставшихся трех – два свободные и один резервный. Да, несмотря на то что пинкодов осталось только три, два из них свободные. Кстати, самое время обратиться на линию лицензирования и получить еще два резервных пинкода. 👆А вот теперь подводные камни. На тех ПК, где у нас лицензии с заблокированными пинкодами сами файлы программной лицензии никуда не делись и при запуске 1С они продолжат работать как ни в чем не бывало. Но 1С отслеживает общее количество активных лицензий и у вас может начаться случайный их «слет». Т.е. сегодня лицензия не обнаружена у Иванова, завтра у Петрова, а Иванов снова нормально работает. И если не изучать лог поиска ключа, то искать причину можно очень долго и безуспешно. Также может помочь запрос на линию поддержки, они покажут вам какие пинкоды дублируются и на каких ПК это происходит, далее только останется найти ПК по имени. ✅ Поэтому, во избежание разных проблемных ситуаций удаляйте файлы программных лицензий с выводимых из эксплуатации ПК. А также ведите учет пинкодов и указанной при их активации информации о пользователе, которую, напоминаем, надо восстановить посимвольно. Все это, конечно, можно восстановить через линию поддержки, но это занимает время. Также, при активации лицензий, указываете доступную и активную почту, а не почту пользователя или директора/главбуха. Потому что иначе переписку с поддержкой вам придется вести через их ящик, либо предоставлять кучу дополнительной информации или довольствоваться тем, что информация на сторонний почтовый ящик будет ограничена.

Статус Сколково "под ключ" снизить налоги до 0% Боитесь тратить деньги впустую и не получить статус? Мы берем на себя все риски. Наша команда (14 узкопрофильных экспертов) проведет вас в резиденты «Сколково» с гарантией результата. Условия сделки: Если статус не будет получен — мы возвращаем деньги 100% или делаем повторную подачу бесплатно. Результат: выход на льготы (0% прибыль, 0% НДС, 0% имущество) всего за несколько месяцев. Окупаемость услуги — 2 месяца вместо 10 лет Перейти на сайт #реклама audit.glsexpert.ru О рекламодателе

Кто сильно переживал за ПИоТ - может выдохнуть и немного расслабиться. С 1 июля продажи не станут и проверка марок в разрешительном режиме работать будет. Штрафные санкции откладываются на 1 сентября. Но расслабляться и откладывать на потом внедрение ПИоТ не нужно. Чтобы он не свалился вам как снег на голову.