Удаленный хост принудительно разорвал существующее подключение код ошибки 0x00002746 wsaeconnreset

SkaRzn
Новичок

Зарегистрирован: 19.02.2019
Пользователь #: 170,608
Сообщения: 69

Источник

Fix: Active Directory Domain Controller Could Not Be Contacted

In this article, we’ll take a look at why it’s not possible to join a new computer to the Active Directory domain with an error Active Directory Domain Controller could not be contacted.

Active Directory Domain Controller Could Not Be Contacted Error: What Does It Looks Like?

A user or an administrator tries to join a new Windows workstation or server to the domain. To do this, open the System Properties on the workstation, and press Change settings > Change. Enter a new computer name, and select that this computer should be a member of a specified domain. Enter your AD domain FQDN name. After clicking on the OK button, you may receive an error:

An Active Directory Domain Controller (AD DC) for the domain “theitbros.com” could not be contacted.

Ensure that the domain name is typed correctly.

If the name is correct, click Details for troubleshooting information.

How to Fix AD Domain Controller Could Not Be Connected Error?

Here are some basic steps that should help you fix the domain controller connection error:

1. Check your IP address and DNS settings;
2. Check the Active Directory domain controller connectivity;
3. Check DC Health (SRV DNS records, Netlogon, and Sysvol folders).

Let’s look at each of these steps in more detail.

Check the IP Settings and DNS Settings on Your Computer

Most often, this problem is related to the wrong IP or DNS settings on your computer.

Check IP Address

First, check if your computer has the correct IP address on the primary network interface. The IP address can be obtained from a DHCP server, or manually specified in the network adapter settings. You can view the current network settings of the computer using the command:

Make sure your computer’s IP address matches the network it’s on. Try to manually set a static IP address, or vice versa, get the correct address from the DHCP server (select Obtain IP address automatically in the properties of your network adapter).

Check DNS Client Settings

Make sure your network adapter’s IP settings are set to your internal DNS servers. You can display the current DNS servers for your adapter using PowerShell:

If the DNS server address is incorrect, change it manually or get settings from DHCP.

Make sure the DNS Client service is running using Get-Service cmdlet:

Open the hosts file (C:WindowsSystem32Driversetchosts) on the computer using notepad.exe or another text editor, and make sure there are no entries for your domain or domain controller names. If such entries exist, delete them.

You can display the contents of the hosts file with the command:

Then clear the DNS cache, and restart the service from the elevated command prompt:

Check if your computer can resolve the domain name to the correct IP address of the domain controller. Use the Resolve-DNSName cmdlet with the FQDN of your domain to which you are trying to join your workstation:

The command should return one or more records of DNS servers.

Verify the Domain Controller Connectivity

Next, check if the domain controller is accessible from the client. Open a command prompt, and run the following commands:

Make sure your domain controller is responding and reachable.

Note. In addition, it’s recommended to check the availability of the domain controller from other workstations on the same IP network.

If the DC is reachable, try to add the received IP address as a DNS server in the Advanced TCP/IP settings of your network connection.

1. Open Control Panel > Network and Internet > Network and Sharing Center > Change adapter settings;
2. Select a network adapter that is connected to your corporate network, right-click on it, and select Properties;
   
3. Select Internet Protocol Version 4 (TCP/IPv4), and click Properties;
4. Press the Advanced button, and go to the DNS tab;
5. On the DNS tab press Add, and enter the IP address of your DNS server (domain controller). Don’t use Public DNS IPs in preferred and alternative fields, like 8.8.8.8 (google) or 1.1.1.1 (cloudflare);
   
6. Click OK (if several IP addresses are listed in the DNS server list, move the IP address of your DC to the top of the list);
   
7. Save the changes and restart the workstation;
8. Try to join your workstation to the AD domain.

Check If the Domain Controller Connections Aren’t Blocked By the Firewall

Verify if the access to the DNS service on the domain controller is not blocked by firewalls. The easiest way to check the availability of port 53 on a DC is to use PowerShell:

In our example, TcpTestSucceeded: True means that the DNS service on the DC is accessible.

Also, make sure the computer can contact the DNS server that hosts the DNS zone or can resolve DNS names in that domain. Make sure the correct DNS server is configured on this client as preferred and the client is connected to this server. Confirm you can find a domain and access the domain controller from the computer using the command:

If your computer successfully discovered the domain and domain controller, the command should return information about the domain, AD site, and services running on the DC:

Hint. Another helpful guide that can help you troubleshoot DC connectivity over RPC is “The RPC Server is Unavailable”.

Also, try to temporarily disable the built-in Windows Firewall, and all third-party applications with antivirus/firewalls modules (Symantec, MacAfee, Windows Defender, etc.), that can block network ports to access the domain controller. After disabling the firewalls, try to join the computer to the domain.

Here is the minimum list of network protocols, ports, and services that must not be blocked in firewalls between a client and a domain controller to successfully join a device to the Active Directory domain:

• UDP 53 — DNS traffic;
• TCP and UDP 88 — Kerberos authentication;
• UDP 123 — Windows Time Sync with DC;
• TCP 135 — Remote Procedure Call RPC Locator;
• TCP and UDP 139 — NetBIOS Session Service;
• TCP and UDP 389 (LDAP, DC Locator, Net Logon) or TCP 636 (LDAP over SSL);
• TCP 445 (SMB/CIFS, Net Logon);
• TCP 49152-65535 — RPC ports, randomly allocated high TCP ports.

Check the DNS SRV Records on the Domain Controller

Check DNS Records on your DC

If the above method didn’t help, check if in the DNS zone of your domain controller there is an SRV record of the location of the DC.

Open an elevated Command prompt, and run the following commands:

Verify if the specified DNS server has an SRV record in the following form:

If the specified SRV record is missing, it means your computer is configured to use a DNS server that does not have a correct SRV record with the location of the domain controller.

Update/Re-Register DNS SRV Records on DC

If you can’t change the DNS settings on your computer, you can manually add two records (SRV and A) to your existing DNS server which help you to resolve the domain controller’s IP address:

• _ldap._tcp.dc.msdcs.your_domain_name.com — is an SRV resource record that points to the domain controller that hosts the ADDS role;
• Resource A record that identifies the IP address for the DC listed in the _ldap._tcp.dc.msdcs.your_domain_name.com SRV resource record.

Restart the Netlogon service on the domain controller with the command:

(or simply try to reboot the DC)

On startup, it will try to register the necessary SRV records on the DNS server.

Also, you can re-register domain controller DNS records using the command:

Wait for a while for the records to appear in DNS and replicate across the domain.

Also, make sure the dynamic updates are allowed in your Windows DNS zone settings.

Check the Domain Controller Health

Perform a health check on your domain controllers and replication according to the following guides:

It is also recommended to verify if the SYSVOL and NETLOGON network shared folders are created and accessible on the domain controller (run the net share command on the closest DC).

If the SYSVOL and NETLOGON directories are missing in the shares list:

1. Check the IP and DNS settings on your DC (the domain controller shouldn’t receive an IP address from a DHCP server, use only a static IP address);
2. Verify if the C:WindowsSYSVOL domain directory contains Policies and Scripts folders;
   
3. If you did not migrate Sysvol replication from FRS to DFS, to replicate Sysvol from PDC to all DCs in the domain, you need to stop the File Replication Service (net stop NtFrs). Then run the Regedit and go to the registry key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup, here change the value of BurFlags DWORD parameter to D4 (hex) on PDC, and to D2 (hex) on all additional domain controllers. After that, start the service:

And check if the directory DCName SYSVOL appears and is accessible on the problem DC.

Troubleshooting Error “an Active Directory Domain Controller Could not be Contacted”

If none of the above methods helped you to fix the problem, you need to move to more advanced troubleshooting. Note that the Details button is available in the error message.

Click the Details button for more information about the error. In most cases, there you will see an error “DNS name does not exist” or one of the following error codes 0x0000232B RCODE_NAME_ERROR, 0x0000267C DNS_ERROR_NO_DNS_SERVER, and 0x00002746 WSAECONNRESET).

The domain name “DOMAIN_NAME” might be a NetBIOS domain name. If this is the case, verify that the domain name is properly registered with WINS.

If you are certain that the name is not a NetBIOS domain name, then the following information can help you troubleshoot your DNS configuration.

The following error occurred when DNS was queried for the service location (SRV) resource record used to locate an Active Directory Domain Controller (AD DC) for domain “DOMAIN_NAME”:

The error was: “DNS name does not exist.”

(error code 0x0000232B RCODE_NAME_ERROR)

The query was for the SRV record for _ldap._tcp.dc._msdcs.DOMAIN_NAME

Common causes of this error include the following:

– The DNS SRV records required to locate a AD DC for the domain are not registered in DNS. These records are registered with a DNS server automatically when a AD DC is added to a domain. They are updated by the AD DC at set intervals. This computer is configured to use DNS servers with the following IP addresses:

– One or more of the following zones do not include delegation to its child
zone:

Domain_name
local
.. (the root zone)

Open the text file C:windowsdebugdcdiag.txt on the user’s computer. Carefully study the latest errors in this file. Perhaps they will point you in the right direction.

Most often, you can face such errors in the dcdiag.txt file:

• 0x0000232B — RCODE_NAME_ERROR (“DNS name does not exist”) – your computer cannot find the SRV record on the DNS server. Make sure your computer’s DNS settings are set to the IP address of your domain controller. Check SRV records on DC;
• 0x0000267C — DNS_ERROR_NO_DNS_SERVER (“No DNS Servers configured for local system”). In this case, it is recommended to check your IP and DNS settings, and network connectivity;
• 0x00002746 — WSAECONNRESET (“An existing connection was forcibly closed by the remote host”) — check the network connectivity and firewall rules. Try to restart the DNS service on the DC, or reboot the host completely.

Sometimes, in the Netsetup.log file, you can find useful information about errors in joining a computer to an Active Directory domain. It is Windows clients log the details of the domain join operation. This log can be found here %windir%debugNetsetup.log. Carefully examine the errors in the Netsetup.log file, they may help you in finding the problem of not being able to connect to the Active Directory domain.

The most typical errors are:

• An attempt to resolve the DNS name of a DC in the domain being joined has failed. Please verify this client is configured to reach a DNS server that can resolve DNS names in the target domain;
• An operation was attempted on a nonexistent network connection — restart the computer, make sure that you type the DNS name and not the NetBIOS name;
• Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again — reboot your device;
• Network name cannot be found — make sure your computer can access the DNS server hosting the domain’s DNS zone;
• No more connections can be made to this remote computer at this time because there are already as many connections as the computer can accept — remove all mapped drives and reboot the computer.

Источник

Adblock
detector

Содержание:

1.    Переход на последнюю версию платформы 1С как решение ошибки

2.    Очистка кеша на сервере для решения проблемы

3.    Исправление проблемы с подключением IPv6

Возникновение ошибки «Удаленный хост принудительно разорвал существующее подключение с 1С» зачастую сопровождается кодом 10054 (0x00002746). Откуда возникает эта ошибка и как ее исправить – об этом мы поговорим в данной статье.  

1.     Переход на последнюю версию платформы 1С как решение ошибки

Если у вас появилась ошибка «Удаленный хост принудительно разорвал существующее подключение», возможно, Вы совершили переход с одной версии на платформы на другую. В таком случае для исправления ошибки следует перейти на последнюю версию платформы 1С, которая будет более стабильной, или откатиться назад, если имел место переход на экспериментальную версию платформы. Хотя стоит отметить, что разработчики платформы, оперативно исправляют существенные баги. И с этой ошибкой были замечены всего лишь несколько версий платформы, которые уже канули в лету.  

2.   Очистка кеша на сервере для решения проблемы

Изменение версии платформы – не единственная из возможных причин возникновения ошибки «Удаленный хост принудительно разорвал подключение (10054)». Соответственно, обновление или откат также не являются универсальными решениями проблемы. В любом случае, если вы рядовой пользователь, Вам надо обращаться к системному администратору. Своими действиями вы никак не могли вызвать данную ошибку. Если же Вы специалист и ищете решение данной проблемы, то первым делом надо заняться очисткой кеша на сервере, очистить все сессии и перезагрузить сервер. 

Также не стоит забывать о такой простой вещи, как недостача свободного места на диске, где установлен SQL сервер. Одно из вытекающих решений – очистка памяти. Наконец, одно из популярных решений, которое помогает с этой проблемой, если вас 32 битный 1С сервер, это установка 64 битной версии 1С сервера. Если ничего из вышеперечисленного не помогло, то следует попробовать сжать базу, перезапустить службы агента сервера 1С, попробовать сделать выгрузку/загрузку.  

3.     Исправление проблемы с подключением IPv6

Ещё один нередкий случай: ошибка «Удаленный хост принудительно разорвал существующее подключение (10054)» возникает по причине подключения IPv6. Проверить это можно, открыв командную строку и выполнив команду Ping по имени вашей страницы. Проверьте адрес – по ответу сразу будет понятно, какой протокол в приоритете. Если это так, то следует отключить IPv6 через системный реестр и перезагрузить компьютер. Это можно сделать, создав запись в разделе HKLMSYSTEMCurrentControlSetservicesTCPIP6Parameters, запись «Параметр DWORD (32-бита)» с именем «DisabledComponents» и значением 0xff.

Специалист компании «Кодерлайн»

Юрий Сахно

Лечим 54ю ошибку в 1С

 Описание ошибки

server_addr=tcp://<имясервера>:1562 descr=Ошибка сетевего доступа к серверу (Windows Sockets — 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение.) line=1031 file=.srcDataExchangeTcpClientImpl.cpp

Как бороться с этой проблемой

Настроить Технологический журнал и разобрать его логи.
Наиболее частыми причинами бывают падения серверной части 1С:Предприятия.
В также можно убедиться, посмотрев — ане создаются ли дампы (смотреть путь logcfg.xml, если настройка dump-ов в нем отсутствует, то в каталоге %USERPROFILE%Local SettingsApplication Data1C1Cv81Dumps, например C:Documents and Settings<Имя пользователя>Local SettingsApplication Data1C1Cv81dumps. Падения платформы чаще всего могут возникать из-за запросов с нестандартными параметрами. Дампы отсылайте в техподдержку 1С email:v8@1c.ru.
1. Чаще всего мне встречалась проблема в журнале документов в отборах запросы были похожи на этот:

SELECT ALLOWED TOP 35 R.Date_Time A1,
R.Number A2,
R.Fld9608 A3,
R.Fld9613 A4,
R.Fld9606 A5,
R.Fld9610 A6,
R.Fld9611 A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609 A12,
R.Fld9605 A13,
R.Document A14,
R.Marked A15,
R.Posted A16,CAST(R.Fld9608 AS REF(Reference9)).Description
A17,CAST(R.Fld9606 AS REF(Reference52)).Description A18,CAST(R.Fld9611
AS REF(Reference93)).Description A19, CASE WHEN R.Fld9609 REFS
Reference53 THEN CAST(R.Fld9609 AS REF(Reference53)).Description WHEN
R.Fld9609 REFS Reference150 THEN CAST(R.Fld9609 AS
REF(Reference150)).Description WHEN R.Fld9609 REFS Reference63 THEN
CAST(R.Fld9609 AS REF(Reference63)).Description WHEN R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).Description END
A20,CAST(R.Fld9605 AS REF(Reference79)).Description A21
FROM DocumentJournal9604 R WHERE
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) AND
(R.Date_Time > DATETIME(2006,12,31,12,0,0) OR (R.Date_Time =
DATETIME(2006,12,31,12,0,0) AND (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
ORDER BY A1 ASC, A14 ASC’

2. Пример лога ТЖ, показывающее причину падений сервера при обновлении полнотекстового поиска
11:40.9690-0,EXCP,1,process=rphost,p:processName=<база данных>,t:clientID=3, t:applicationName=BackgroundJob,t:connectID=27,Usr=DefUser,DumpFile=C:Program Files (x86)1cv81dumpsrphost_8.1.13.41_7d4e2366_20090609021136_10236.mdmp,Context=’
ОбщийМодуль.МодульРегламентныхЗаданий : 46 : ПолнотекстовыйПоиск.ОбновитьИндекс(Ложь, Истина);’

Итоговым решением в этом примере будет отключить фоновый процес в проблемной базе. Дождаться нового релиза платформы и обновиться.
Более подробно про падения платформы смотрите в моем блоге.
3. Пример ТЖ для циклический перезапуск процессов. Для анализа этого события на компьютере сервера 1С:Предприятия необходимо включить запись в технологический журнал событий PROC (пример файла logcfg.xml).
Когда процесс выключается, будет выведено событие PROC со свойством Txt=Process become disable.
Когда процесс останавливается, будет выведено событие PROC со свойством Txt=Process terminated. Any clients finished with error. Если аварийные завершения работы пользователей совпадают по времени с выводом этого события, то причиной является принудительная остановка рабочего процесса либо администратором (через консоль кластера), либо вследствие автоматического перезапуска.
4. Убедиться, что причиной являются/не являются действия администратора в консоли

—————————-

Ниже представлен вариант решения коллегой.

Всем заинтересованным в решении проблем с падением платформы с ошибками:

10051, 10053, 10054, 10064

Как показал разбор полетов по падениям платформы, с выше указанными ошибками:

— Большинство падений вызвано именно работой фоновых заданий, как и предполагалось в топике.

— Не хваткой дискового пространства

— Наличием большого числа не завершенных транзакций в журнале 1С

* * *

— Прежде чем заниматься разбором с технологическим журналом, проанализируйте используемые в конфигурации фоновые задания и отключите те, которые не требуются Вам для работы, конфигурации (банально, анализ 14 ГБ мусора можно считать времяпрепровождением, если Вам нечем заняться… :))) )

— Проанализируйте и внесите исправления в дописанные Вами фоновые задания, убедитесь в том, что они завершаются с нормальным кодом завершения (без ошибок и не закрытых транзакций)

— Внесите в алгоритмы фоновых заданий фрагменты кода, ошищающие, принудительно, память используемую в ходе их работы (Не стоит надеяться на то, что 1С при завершении особождает использованную память)

— Проанализируйте и ИСПРАВЬТЕ ПРОБЛЕМЫ ФУНКЦИОНИРОВАНИЯ типовых фоновых заданий конфигурации

— Выполните регламентные процедуры с базой данных, через пункт меню Администрирование-Тестирование и исправление, не забудьтеобязательно, выполнить сжатие базы данных

— Проанализируйте объем используемого пространства сервером SQL, вероятно что серверу банально нехватает памяти

— Проверьте политки настройки Active Directory

— И также сожмите/очистите журнал транзакций SQL вот примерно таким кодом (для SQL 2000):

Если после этих операций падения продолжаются, тогда продолжайте следовать рекомендациям:

— Пробуйте внести изменения в файлы HOSTS операционной системы (вероятнее всего будет достаточно прописать ассоцирование только в файлы на одной/двух машинах, где падения происходят наиболее часто)

— Пробуйте разнести сервера 1С предприятия и SQL, если они у Вас на одной машине.

— Или наоборот установите их на одной машине (если хватает ресурсов) Отмечаются случаи, когда именно перенос серверов на один сервер помогало (На мой взгляд очень сомнительно и больше относится именно к причине начала работы, это сжатие журналов транзакций)

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

— Проверьте работу маршрутизаторов в сети (Редко, но бывает, что именно их перенастройка влияет на количество падений)

— Проверьте конфликты оборудования в сети (это к вопросу, почему желательно иметь оборудование одного поставщика в сети. Кто хочет может проверить, например, в тех. документации 3COM написано: если сетевая карта обнаруживает, что взаимодействует с аналогичной сетевой картой, то она может быть переключена в более производительный режим, засчет перехода на оптимизированный алгоритм обработки сетевых пакетов, проверено на личном опыте скачок производительности до 50%)

— Проверьте уровни сигналов у потребителей/конечных компьютеров (может быть банально, низкий уровень сигналов, постоянные повторные запросы блоков, задержка очереди на обслуживание в сети, а следовательно в конце концов получение сообщения, что конечный серевер разорвал соединение, когда количество попыток превысит время ожидания поступления сигнала. Если хотите разобраться в данном вопросе обратитесь к протоколу работы Ethernet/CSMA CD/CSMA. Количество попыток в передаче пакета по данному протоколу не бесконечно… ))) Да и буфер в картах тоже не беспределен.)

— Добавьте памяти на сервера

— Переведите часть/всех пользователей в терминальный режим (Т.е. обеспечьте то, что МНОГИЕ пользователи определеяют как ТОНКОГО КЛИЕНТА 1C). В качестве такого сервера я бы рекомендовал Citrix Metaframe или Terminal Server MS

Вероятнее всего, когда Вы выполните указанные рекомендации, за исключением разбора проблем с железом, стабильность работы возрастет настолько что падения платформы станут очень редкими, что перекроют технологические промежутки по обслуживанию базы данных, выполнять которые всеже НЕОБХОДИМО и не думайте, что те рекомендации что указаны выше Панацея от всех проблем.

Они решат многие, но не все проблемы.

И счастливы Вы, если у Вас нет таких проблем, у кого они есть, тот меня поймет.

(С) Шарафан Александр (AXELOT, Москва)

———————————

Ряд проблем связан с утечками памяти.
1. Перезагрузите сервер.
2. Если у Вас 1 рабочий процесс, добавьте еще несколько, чтобы иметь возможность переподключиться в случаи сбоя рабочего процесса.

3. Если у Вас 32х разрядна версия сервера 1С, то пора купить 1С:Предприятие 8.2. Лицензию на сервер (x86-64).

Исследуйте роли «Пользователя», если они есть в типовой конфигурации конечно, и в частности, после того как вычислите проблемныйдокумент с помощью ТЖ, нужно найти проблемную роль (кто жалуется).
Далее для роли Пользователя смотрим РЛС документа, если дополнительных настроек нет (чисто), то правой кнопкой на нем — поиск ссылок на объект, и последовательно просматриваем РЛС для роли «Пользователь» для каждого объекта.

Ошибочное принятие высокой интенсивности пользователей за атаку на протокол в некоторых случаях Windows.
>Запустить программу regedit.exe, добавь новое значение типа DWORD с именем SynAttackProtect в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и присвой ему значение 00000000
Имеет смысл делать для ОС Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx).

p.s. Кроме того, 54 ошибку можно получить на релизах <= 8.1.12.98 при ри конвертации конвертором ИБ 77(DBF) -> 81(SQL) в типовой ТиС (демо, взятой с ИТС) релиз. 954 в клиент-серверном варианте.
обойти можно так:
— выполните конвертацию в файловый фариант информационной базы 1С:Предприятия 8.1,
— выгрузите полученную информационную базу в файл,
— загрузите в клиент-серверный вариант информационной базы 1С:Предприятия 8.1.

Собрать логи ТЖ можно файлом logcfg.xml.

1С ошибка 10054 на Debian Squeeze

серый КТУЛХУ

28.10.21 — 14:38

серый КТУЛХУ

1 — 28.10.21 — 14:42

прим.: админ грит IPv6 отключил — не помогло.

asady

2 — 28.10.21 — 14:42

МихаилМ

3 — 28.10.21 — 14:43

в поиск. видел такую тему

серый КТУЛХУ

4 — 28.10.21 — 14:44

серый КТУЛХУ

5 — 28.10.21 — 14:47

Garykom

6 — 28.10.21 — 14:47

(0) ВК валит сервер 1С

Garykom

7 — 28.10.21 — 14:48

(6)+ отрубить регламентные/фоновые и рестартануть

Garykom

8 — 28.10.21 — 14:48

(6)+ это одно из предположений

Dmitrii

9 — 28.10.21 — 14:50

серый КТУЛХУ

10 — 28.10.21 — 14:51

серый КТУЛХУ

11 — 28.10.21 — 14:52

* «слк-лицензирование»

Garykom

12 — 28.10.21 — 14:52

(10) rphost рестартует к примеру

МихаилМ

13 — 28.10.21 — 14:54

Dmitrii

14 — 28.10.21 — 14:55

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:srvinforeg_1541"
set PFL_PATH="C:ProgramData1C1cv8"
set TEMP_PATH="C:WindowsTemp"
echo stop %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%snccntx*
DEL /Q /F %PFL_PATH%*.pfl
DEL /Q /F /S %TEMP_PATH%*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%

серый КТУЛХУ

15 — 28.10.21 — 15:09

shuhard

16 — 28.10.21 — 15:25

Dmitrii

17 — 28.10.21 — 15:32

серый КТУЛХУ

18 — 28.10.21 — 15:55