Вы через редактор локальной политики (gpedit.msc) смотрите, наверное - т.е. в оснастке Group Policy Object Editor, нацеленной на локальный компьютер? Так там показываютсят (и меняются) настройки из объекта локальной политики, а настроки результирующей политики не показываются (ЕМНИП, раньше в Win2K показывались, но с тех пор много воды утекло).
А настройки результирующей политики в аналогичном виде можно увидеть в консоли rsop.msc (в оснастке Resultant Set of Policy.
Drno, ага, вы вспомнили правильное слово. Чего бы вам раньше было его не вспомнить, до того, как отвечать? Или вы были не в курсе, что эта функциональность часто встраивается в почтовые сервера?
В любом случае, ваш ответ вводит людей в заблуждение, а это нехорошо.
Вы знаете недостаточно. Например, в MS Exchange возможность перенаправления сообщений для конкретных получателей на другой (другого типа) сервер - это штатная возможность (делается с помощью почтового домена внутренней ретрансляции и контактов для этих конкретных получателей). В древнем sendmail это тоже делается - через alias в sendmail.cf. То же можно сделать в и чуть менее друвнем MDaemon. Это - те решения, которые я реально делал.
А так, подозреваю, эта функциональность есть во множестве других почтовых серверов.
Игнат Соколов, нет, надо писать e:Имя_файла.cs. Да ещё, возможно, и полный путь до нужного каталога от корня диска E: придётся добавить - если у вас текущий каталог для диска E: - другой (Windows, соблюдая традиции DOS, хранит текущий каталог для каждого диска).
Ну, или перед запуском команды переходите в нужный каталог.
Клиенты и MX - это две разницы. MX - это про доставку почты в конкретный домен, а клиентам надо отправлять почту, причем - во все домены. Поэтому клиенты на MX-записи обычно не смотрят: у них есть свои настройки, указывающие на почтовый сервер, который будет заниматься маршрутизацией почты (разве что, при своей автонастройке посмотреть могут).
Не распространяйте заблуждения.
1. Windows уже давным-давно умеет скрывать недоступные общие папки целиком и отдельные папки внутри общих папок (называется это access- based enumeration)
2. Общая папка с парольным доступом здесь неуместна, потому что речь идет уже о доступе разных пользователей.
Короче, прежде чем давать советы, учите матчасть.
Правильный вопрос, как известно, содержит половину ответа. А ваш вопрос ее не содержит. Например, вы не указали значение чего надо вытащить - хотя бы на уровне того, где вы его видите (на экране, в файле и т.п.).
Пожалуйста, дополните ваш вопрос этой и другими подробностями, которые вам могут показаться нужными.
Иначе нам тут придется дожидаться телепата, который прочитает нужные для ответа данные прямо в вашем мозгу, или ясновидящего, который сможет увидеть их в своем хрустальном шаре.
PS Мой комментарий такой язвительный по форме потому, что мне показалось, что вы даже не взяли на себя труд подумать над вопросом, а решили напрячь сообщество, не напрягаясь сами. Если я ошибаюсь, то приношу свои извинения за форму. Но содержания это не отменяет: для ответа на ваш вопрос данных недостаточно.
Дык, я разве про учетные записи пользователей писал? Я писал про учетные записи компьютеров - надеюсь, разницу понимаете?
Но вообще-то, мне чисто для себя хочется поинтересоваться, про какие ключи вы тут пишете: с этого места, пожалуйста, поподробнее - если можете, конечно.
PS А если в целом, то при восстановлении КД в сущестующую и функциоирующую AD все обновления содержимого БД AD реплицируются на восстановленный КД, и любые ключи в этой БД будут ровно те же. Но чтобы это произошло, КД долже быть способен аутентифицироваться на другом КД для репликации, и тут как раз вступает в действие срок жизни пароля: если он истек и был поменян после резервного копирования, то будут проблемы (впрочем, решаемые - этот пароль сбросить и переустановить можно, процедура в документации описана).
Drno, а зачем вообще какие-то ещё (опенсорсные или нет) сторонние решения, когда есть решение, уже входящиев состав ОС - не задумывались, а?
В частности, комерческие же решения нужны, чтобы снизить трудозатраты на функционирование информационной системы. Именно за это снижение трудозатрат предприятия готовы платить деньги их производителям.
Но я писал не об этом, а о том, что использование решений для резервного копирования, не поддерживающих AD специально, может просто нанести вред. Вы за предложенные вами решения готовы отвечать, что они AD поддерживают? Или вам главное, что они идеологически правильные - опенсорсные.
Под "ключами шифрования", если я правильно понял, имеются в виду пароли учетных записей компьютеров домена. Они, да, переоически меняются (по умолчанию - раз в 30 дней), впрочем AD всегда хранит и предыдущую копию. Но по истечении 30 дней может потребоваться сбрасывать паролиучетных записей компьютеров (особенно - восстанавливаемого КД),. Кроме того, в AD есть и другие ограничители времени: время годности данных DFSR (для репликации SYSVOL), по умолчанию - 90 дней (если его в последних версиях не поменяли), и время жизни захороненных (удаленных) объектов в базе AD, по умолчанию - 180 дней.
Так что нельзя просто так вязть и сделать один раз резервную копию AD и на этом успокоиться. Резервную копию нужно делать регулярно, не реже чем раз в месяц.
Ваш совет - вредный, годится только для сетей с ровно одним контроллером домена. Потому что база AD - распределенная, ее узел нельзя просто так взять и скопировать, а вотом восстановить. Почему так - ищите и читайте материалы на тему "USN rollback".
PS Не нравится встроенное средство архивации Windows - используйте коммерческое решение. Только деньги за него заплатите ;-).
Ну-ну... А что вы будете делать, если из строя выйдет вся AD? Например - из-за вовремя необнаруженного и расползшегося по контроллерам рассогласования из-за USN Rollback? Если чо - такой случай на практике я знаю: не из моей лично рабочей, но когда-то я помогал одному страдальцу отползти из такой ситуации на форуме MS Technet. Он отполз, кстати.
PS А ещё есть практика грузить сервера КД другими функциями. Особенно это было популярно в прошлую эпоху, когда виртуализация была чем-то далеким: простаивающее, по сути, железо вводило в соблазн.
PS Автору вопроса: неплохо бы указывать на какое место в тексте указывают координаты в сообщении об ошибке: мы тут это определить не можем, а вы - запросто.
Потому что DispatchMessage отправляет это событие в оконную процедуру дочернего окна, так как оно лежит выше. Аналога погружения/всплытия событий, как в JS в браузере, в Windows нет. Оконная процедура элемента управления может оповещать о некоторых событиях свое родительское окно (для этого есть специальные коды сообщений), но ЕМНИП перемещение мыши без нажатия клавиш к таковым не относится.
Евгений Шатунов, конкретно по вопросу, поддерживается ли ABI С в С++ вопроса нет: поддерживается.
Вопрос тут в другом: не желал ли автор вопроса узнать по поддержку ABI для возможностей, отсутствующих в C, но имеющихся в C++ (он их там в вопросе перечислил), или ему хватит возможностей C. Думаю, уточнить это может только автор вопроса, Сергей Соловьев , если ему это ещё интересно.
А вот с ABI для специфичных для C++ возможностей AFAIK все плохо. В частности, в Википедии там на эту тему сплошное "бы", типа "хорошо бы".
Евгений Шатунов, нет, я хочу сказать, что автора вопроса (как я его понял из-за упоминания классов и перегрузок), интересовала та функциональность C++, которая находится за пределами функциональности C.
Сергей Соловьев, я по современному C++ не специалист и могу чего-нибудь недоучесть. Так что, могу дать только комментарий со своим скромным мнением, а за большее ответсвенность не возьму.
AFAIK никак. И вряд ли это возможно. Ибо вы хотите реально совместимый между компиляторами ABI - а его в эту реальность не завезли. И отсутствие единообразия в искажении (или украшении, как некогда писали в Borland) имен функций - это далеко не главная проблема на пути его реализации. К примеру, есть ещё несовместимость форматов VTABLE - и это IMHO куда страшнее.
А настройки результирующей политики в аналогичном виде можно увидеть в консоли rsop.msc (в оснастке Resultant Set of Policy.