შესავალი

კლიენტმა მოგვმართა პრობლემით: Revit-ის File → Open ფანჯრის მარცხენა სვეტში არ ჩანსო Revit Server.  L1-ის თქმით ამავე დროს კომპიუტერი სერვერს ქსელის საქაღალდით (share) უპრობლემოდ უკავშირდებოდა, ხოლო სხვა კომპიუტერებიდან Revit Server რევიტში ჩვეულებრივად ჩანდა და პროგრამის გადაყენება უკვე ცადეს.

 

როგორ უკავშირდება Revit სერვერს

სანამ პრობლემის ძებნას დავიწყებდი, ჩემთვის მნიშვნელოვანი იყო გამეგო, რისგან შედგება ჯაჭვი „Revit → Revit Server“. გადავწყიტე ნაბიჯ-ნაბიჯ მივყოლოდი ცნობილ სოლუშენებს

  1. კლიენტის კონფიგურაცია. Revit სერვერის მისამართს კითხულობს ფაილიდან C:\ProgramData\Autodesk\Revit Server 20XX\Config\RSN.ini. წელი საქაღალდის სახელში ზუსტად უნდა ემთხვეოდეს Revit-ის ვერსიას.
  2. ქსელი. Revit Server მუშაობს IIS-ის მეშვეობით HTTP-ით (პორტი 80). ქსელის საქაღალდის (SMB) ხელმისაწვდომობა აქ არაფერს ამტკიცებს: ეს სხვა პროტოკოლი და სხვა სერვისია.
  3. სერვერი. სერვერზე დაინსტალირებული უნდა იყოს Revit Server-ის იგივე ვერსია, რაც კლიენტის Revit-ია. ერთ სერვერზე რამდენიმე ვერსია შეიძლება ერთდროულად იდგეს.
  4. თავად Revit. პროგრამაშის რომელიმე მოდული პასუხისმგებელი იქნება RSN.ini-ის წაკითხვაზე. ეს რგოლი ყველაზე რთული საპოვნელია, და პრობლემაც სწორედ აქ აღმოჩნდა.

 

ნაბიჯი 1: კლიენტის კონფიგურაცია

პირველ რიგში დავადგინე ვერსიები, რადგან ვერსიების შეუსაბამობა ამ პრობლემის ყველაზე გავრცელებული მიზეზია. კლიენტზე იყო Revit 2025.3. სერვერზე, საქაღალდე C:\Program Files\Autodesk-ში, ერთდროულად იდგა Revit Server 2024, 2025 და 2026. ესე იგი, სერვერი 2025 ვერსიისთვის მზად იყო.

შემდეგ შევამოწმე RSN.ini კლიენტზე: C:\ProgramData\Autodesk\Revit Server 2025\Config\RSN.ini. ფაილი არსებობდა, შიგნით კი სერვერის სახელი ეწერა. ყოველი შემთხვევისთვის სამი დეტალი  გადავამოწმე:

  • ფაილის გაფართოება. Explorer-ში ტიპი „Configuration settings“ ნიშნავს .ini-ს და არა RSN.ini.txt-ს, რაც Notepad-ში შენახვისას ხშირი შეცდომაა.
  • შიგთავსი. ერთი ხაზი, სერვერის სახელი ან IP, ზედმეტი სიმბოლოების გარეშე.
  • კოდირება. ფაილის თავში უხილავი BOM სიმბოლო პროგრამას სახელის წაკითხვაში  ხელს შეუშლის.
Format-Hex "C:\ProgramData\Autodesk\Revit Server 2025\Config\RSN.ini"

პირველი ბაიტები იყო 52 65 76 69 74, ანუ პირდაპირ ასოები „Revit“, BOM-ის (EF BB BF) გარეშე. ფაილი იდეალური იყო. Revit-ი დავხურე გავხსენი, მაგრამ აიქონი მაინც არ გამოჩნდა

ამ ეტაპზე მივხვდი: თუ ფაილი სწორია და შედეგი არ იცვლება Revit-ი ამ ფაილს საერთოდ არ ან ვერ კითხულობს. ორივე ვერსია მოითხოვდა შემდეგ გამოძიებას.

შედეგი: ფაილი RSN.ini სწორ ადგილას, სწორი შიგთავსითა და სწორ კოდირებაში იყო, მაგრამ აიქონი მაინც არ გამოჩნდა.

ნაბიჯი 2: ქსელი და სერვერი

კლიენტიდან გავუშვი ping Revit-Server, და პასუხი არ მოვიდა. ერთი შეხედვით ეს ქსელის პრობლემას ჰგავდა. მაგრამ ping იყენებს ICMP პროტოკოლს, რომელსაც Windows Server-ის ფაიერვოლი ხშირად ბლოკავს, მაშინ როცა Revit Server HTTP-ით მუშაობს. ამიტომ ping აქ არასწორ კითხვას სვამდა.

სწორი ტესტი ისაა, რომელიც იმავე პროტოკოლს იყენებს, რასაც თავად Revit-ი. კლიენტის ბრაუზერში გავხსენი:

http://%revitisserverisip%/RevitServerAdmin2025/

გაიხსნა Revit Server Administrator-ის გვერდი: როლები Host, Accelerator და Admin, 50 მოდელი, 20 საქაღალდე. ეს ერთდროულად ამოწმებდა სახელის გარკვევას (DNS), HTTP-ს, IIS-ს და Revit Server 2025 სერვისს.

ამავე გვერდზე შევნიშნე წვრილმანი, რომელიც მოგვიანებით გამომადგა: სერვერი საკუთარ თავს წარადგენდა არა სახელით, არამედ IP მისამართით 192.168.0.10. ეს ნიშნავს, რომ სერვერის საკუთარ RSN.ini-ში IP წერია. თანამშრომლების ლოკალური ასლები ცენტრალურ მოდელზე სავარაუდოდ სწორედ ამ მისამართით მიუთითებენ, ამიტომ კლიენტზეც იგივე IP ჩავწერეთ, ერთგვაროვნებისთვის.

შედეგი: ქსელი და სერვერი გამართულია.

ნაბიჯი 3: პირდაპირი ტესტი RSN:// მისამართით

Open ფანჯრის File name ველში ჯერ ჩავწერე მხოლოდ RSN://192.168.0.10/, და არაფერი მოხდა. ეს არაფერს ამტკიცებდა, რადგან მისამართი სერვერზე მიუთითებდა და არა კონკრეტულ ფაილზე. ტესტი უფრო ზუსტი გავხადე და ადმინისტრირების გვერდიდან ავიღე რეალური მოდელის სრული გზა:

RSN://192.168.0.10/House Renovation-CENTRAL.rvt

ამჯერად გამოჩნდა ფანჯარა Model Upgrade: მოდელი Revit 2024-შია შექმნილი, და Revit 2025 მის განახლებას სთავაზობდა. დავაჭირე Cancel Upgrade. ცენტრალური მოდელის განახლება და შენახვა 2024 ვერსიაზე მომუშავე ყველა თანამშრომელს სინქრონიზაციის საშუალებას წაართმევდა.

გამოდის, რომ პირველი: კლიენტს სერვერთან რეალური კავშირი აქვს. მეორე: სერვერზე ზოგი პროექტი 2024 ფორმატშია, ხოლო ოფისში ვერსიები შერეულია. ამიტომ RSN.ini მოგვიანებით სამივე ვერსიის (2024, 2025, 2026) საქაღალდეში ჩავწერე.

მოდელის გახსნა სრული მისამართით ჯერ კიდევ არ ამტკიცებდა, რომ Revit-ი RSN.ini-ს კითხულობს. პირდაპირი მისამართის მითითების შემთხვევაში პროგრამას ეს ფაილი შეიძლება საერთოდ არ სჭირდებოდეს.

შედეგი: Revit-მა სერვერიდან მოდელის გახსნა დაიწყო. კავშირი მუშაობდა, პრობლემა მხოლოდ აიქონის ჩვენებაში იყო.

ნაბიჯი 4: მომხმარებლის პარამეტრები

ვინაიდან ქსელი და ფაილი გამართული იყო, ლოგიკური ეჭვი იყო, რომ Open ფანჯრის მარცხენა სვეტის (Places) სია დაზიანებულია მომხმარებლის პროფილში. ჯერ გადავარქვი სახელი ფაილს %APPDATA%\Autodesk\Revit\Autodesk Revit 2025\Revit.ini, რათა Revit-ს ის თავიდან შეექმნა ნაგულისხმევი პარამეტრებით. არ უშველა 🙁

რეესტრში წავშალე:

HKCU\Software\Autodesk\Revit\Autodesk Revit 2025\Profiles\AllAnavDialogs

Revit-მა სია თავიდან ააგო: პუნქტების რიგი ნაგულისხმევი გახდა, რაც ადასტურებდა, რომ განულება ნამდვილად მოხდა. Revit Server კი ისევ არ იყო.

ეს „უარყოფითი“ შედეგი ძალიან ღირებული იყო. სუფთა პარამეტრებითაც თუ Revit-ი აიქონს არ ამატებს, ესე იგი, პრობლემა არა მომხმარებლის პარამეტრებში, არამედ თავად პროგრამის მხარესაა. ძიების არე მკვეთრად შევიწროვდა.

შედეგი: პარამეტრების განულებამ აიქონი არ დააბრუნა, რაც კიდევ ერთ ვერსიას გამორიცხავდა.

ნაბიჯი 5: Process Monitor — რას აკეთებს Revit სინამდვილეში

როცა სტანდარტული სოლუშენები და ჩექაფი ამოიწურა, საჭირო გახდა დაკვირვება. Sysinternals-ის Process Monitor აჩვენებს ყველა ფაილს და რეესტრის ჩანაწერს, რომელსაც პროცესი ეძებს, და შედეგსაც: SUCCESS, NAME NOT FOUND, ACCESS DENIED.

დავტოვე მხოლოდ ფილტრი Process Name is Revit.exe, Revit-ი ჩაწერის დაწყების შემდეგ გავუშვი. რადგანაც ვიზუალურად ვერ ვნახე rsn.ini-სთან დაკავშირებული რაიმე მოძრაობა, ჟურნალის ანალიზი Claude-ს მივანდე

Save ფანჯარა გავხსენი და მთელი ჟურნალი CSV ფორმატში შევინახე: დაახლოებით 300 000 ჩანაწერი. AI-მ სამი ფაქტი იპოვა:

  1. გაშვებიდან Open ფანჯრამდე არც ერთი მიმართვა C:\ProgramData\Autodesk\Revit Server 2025-ზე. Revit-ი RSN.ini-ს არც ეძებდა.
  2. Places-ის სიაში მე-8 პუნქტად ეწერა Revit Server Network, მაგრამ ცარიელი გზით. ესე იგი, Revit-მა „იცის“, რომ ასეთი პუნქტი უნდა იყოს, მაგრამ მისი ინიციალიზაცია ვერ შეძლო.
  3. Revit-ი რეესტრში წერდა FileNavExtensions\RevitServerView = {456EE4A2-4BF6-4481-827C-8DC1A341E4A2}, შემდეგ კი ეძებდა ამ იდენტიფიკატორს HKCR\CLSID-ში და ყველგან იღებდა NAME NOT FOUND.

{456EE4A2-…} მსგავსი სახელებით, როგორც წესი COM კომპონენტის იდენტიფიკატორები გხვდება. გამოდის Windows-მა არ იცოდა, რომელი ფაილია ეს კომპონენტი, ამიტომ მოდული არ ჩაიტვირთა. შედეგად RSN.ini-მდე საქმე არც მიდიოდა. ევრიკა!

საინტერესოა, რომ იგივე ჟურნალში ჩანდა გარემოს ცვლადი RSACCELERATOR2025=192.168.0.10. ის სწორად იყო დაყენებული და გვაჩვენებდა, რომ კომპიუტერი Revit Server-თან წესით უკვე მუშაობდაი.

შედეგი: Revit-ი RSN.ini-ს საერთოდ არ ხსნიდა, ხოლო Revit Server-ის მოდული ვერ ჩაიტვირთა, რადგან Windows-ში მისი რეგისტრაცია არ არსებობდა.

ნაბიჯი 6: COM რეგისტრაციის აღდგენა

სტანდარტული გამოსავალი Revit-ის Repair ან ხელახალი ინსტალაციაა. მაგრამ L1-ების თქმით Revit ამ კომპიუტერზე უკვე გადაყენებული იყო, და მაინც პრობლემა იყო. ასეთ დროს ნებისმიერი IT იფიქრებს მოდი ავიღო ჯანმრთელი კონფიგურაცია ჯანრმთელი კომპიუტერიდან 🙂

თუმცა ჯერ რეგისტრაციის ხელით აღდგენა ვარჩიე. ამისთვის ორი რამ იყო საჭირო: რომელი ფაილია ის კომპონენტი და როგორ გამოიყურება სწორი ჩანაწერი. თან მაინტერესებდა იქნება თუ არა დამთხვევა ჯანმრთელ კომპიუტერთან. თუ იქნებოდა ესეიგი მიზეზი 100%-იანია.

ფაილის პოვნა. COM იდენტიფიკატორი DLL-ში ბინარული სახით ინახება. ეს თეორიულად ვიცოდი, თუმცა რა მექნა კონკრეტულად არ ვიცოდი, ამიტომ მივმართე Claude-ს და PowerShell-ის სკრიპტი დამიწერა Revit-ის საქაღალდეში ამ ბაიტებს შემცვლელი ფაილის მოსაძებნად:

$hex = [BitConverter]::ToString(([guid]'456EE4A2-4BF6-4481-827C-8DC1A341E4A2').ToByteArray())
Get-ChildItem "C:\Program Files\Autodesk\Revit 2025" -Recurse -Include *.dll -ErrorAction SilentlyContinue |
  Where-Object { $_.Length -lt 50MB } |
  ForEach-Object {
    if ([BitConverter]::ToString([IO.File]::ReadAllBytes($_.FullName)).Contains($hex)) { $_.FullName }
  }

პასუხი: C:\Program Files\Autodesk\Revit 2025\RevitServerView.dll. ფაილი ადგილზე იყო, აკლდა მხოლოდ რეგისტრაცია.

თვითრეგისტრაციის მცდელობა. regsvr32 RevitServerView.dll დააბრუნა შეცდომა „entry-point DllRegisterServer was not found“. ესე იგი, ეს DLL თავს თავად არ არეგისტრირებს; ამას Revit-ის ინსტალერი აკეთებს.

ეტალონი გამართული კომპიუტერიდან. კომპიუტერიდან, სადაც ყველაფერი მუშაობდა, ჩანაწერის ექსპორტი გავაკეთე:

reg export "HKLM\SOFTWARE\Classes\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}" C:\rsview.reg

გეგმის მიხედვით Claude-ს დავადარებინე პრობლემური იდენტიფიკატორი და გამართული კოპმიუტერიდან ამოღებული რეესტრის ფაილი. დამთხვევა 100%. ესეიგი ეს ის არის რაც გვჭირდებოდა.

აღდგენა. პრობლემურ კომპიუტერზე შესაძლებელია ეტალონი კომპიუტერის რეესტრის იმპორტი ან AI-ს მიერ შემოთავაზებული ვარიანტი ადმინისტრატორის cmd-ში:

reg add "HKLM\SOFTWARE\Classes\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}" /ve /d "RevitServerView" /f
reg add "HKLM\SOFTWARE\Classes\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}\InprocServer32" /ve /d "RevitServerView.dll" /f
reg add "HKLM\SOFTWARE\Classes\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}\InprocServer32" /v ThreadingModel /d "Apartment" /f
reg add "HKLM\SOFTWARE\Classes\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}\ShellFolder" /v Attributes /t REG_BINARY /d f0 /f
reg add "HKLM\SOFTWARE\Classes\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}\TypeLib" /ve /d "{4F2B88AA-477B-416E-B3DA-55954DEAAD22}" /f

Revit გავუშვით, და Revit Server Network მარცხენა სვეტში გამოჩნდა.

დასკვნა

მიზეზი იყო დაკარგული COM რეგისტრაცია {456EE4A2-…} → RevitServerView.dll. აღვადგინე ხელით, გამართული კომპიუტერის რეესტრის მიხედვით.

როცა სტანდარტული ცნობილი სოლუშენები ამოიწურა, გამოცნობიდან დაკვირვებაზე გადავედი: Process Monitor-მა აჩვენა არა ის, რაც უნდა მომხდარიყო, არამედ ის, რაც რეალურად ხდებოდა.

ჟურნალში ჩანდა, რას ცდილობდა Revit: რეესტრში წერდა Revit Server-ის მოდულის იდენტიფიკატორს და შემდეგ მის რეგისტრაციას ეძებდა HKCR\CLSID-ში. როცა ეს ჩანაწერები რეესტრის რეალურ მდგომარეობას შევადარეთ, ცხადი გახდა, რა არ გამოსდიოდა: იდენტიფიკატორზე მიბმული კომპონენტი Windows-ში საერთოდ არ იყო რეგისტრირებული, და ყოველ მცდელობაზე Revit-ი იღებდა NAME NOT FOUND.

 

სწრაფი ინსტრუქცია

როცა Revit-ის Open ფანჯარაში Revit Server არ ჩანს, შეასრულეთ ნაბიჯები ზუსტად ამ თანმიმდევრობით. ყოველი ნაბიჯის შემდეგ შეამოწმეთ, გამოჩნდა თუ არა ხატულა.

  1. გაარკვიეთ Revit-ის ვერსია. Revit-ში: „?“ → About. დაიმახსოვრეთ წელი (მაგ. 2025).
  2. გადაამოწმეთ RSN.ini ყველა ვერსიისთვის.
  3. შეამოწმეთ სერვერთან კავშირი. მომხმარებლის კომპიუტერის ბრაუზერში გახსენით http://%yourip%/RevitServerAdmin2025/ (წელი ვერსიის მიხედვით). ping-ს ნუ დაეყრდნობით: თუ სერვერი პინგს არ პასუხობს ეს შეიძლება ნორმალური იყოს. თუ გვერდი არ იხსნება, შეწყვიტეთ და გადაეცით ქსელის/სერვერის პრობლემად.
  4. სრულად გადატვირთეთ Revit. დახურეთ ყველა ფანჯარა და Task Manager-ში შეამოწმეთ, რომ Revit.exe აღარ არის. გაუშვით თავიდან და გახსენით File → Open.
  5. შეამოწმეთ COM რეგისტრაცია. Revit 2025-ისთვის, ჩვეულებრივ cmd-ში: 
    reg query "HKCR\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}" /s

    სხვა ვერსიისთვის იდენტიფიკატორი შეიძლება სხვა იყოს. სწორი ჩანს regedit-ში, მნიშვნელობა RevitServerView გასაღებში HKCU\Software\Autodesk\Revit\Autodesk Revit <წელი>\FileNavExtensions. თუ reg query წერს „unable to find“, მიზეზი ნაპოვნია.

  6. გააკეთეთ Repair. Control Panel → Programs and Features → Autodesk Revit <წელი> → Uninstall/Change → Repair, შემდეგ კომპიუტერის გადატვირთვა. გაიმეორეთ ნაბიჯი 5.
  7. თუ Repair-მა არ უშველა, გადმოიტანეთ ჩანაწერი გამართული კომპიუტერიდან. გამართულ კომპიუტერზე, ადმინისტრატორის cmd-ში: 
    reg export "HKLM\SOFTWARE\Classes\CLSID\{456EE4A2-4BF6-4481-827C-8DC1A341E4A2}" C:\rsview.reg

    ფაილი გადაიტანეთ პრობლემურ კომპიუტერზე და ადმინისტრატორის cmd-ში გაუშვით reg import %sadacgidevt%\rsview.reg. გაითვალისწინეტ რომ იდენტიფიკატორი თქვენი ვერსიისთვის სწორი იყოს (ნაბიჯი 5)

მნიშვნელოვანი: ტესტის დროს თუ Revit-ი მოდელის განახლებას გთავაზობთ (Model Upgrade), ყოველთვის დააჭირეთ Cancel Upgrade. სერვერზე არსებული ცენტრალური მოდელის განახლება სხვა ვერსიაზე მომუშავე თანამშრომლებს სინქრონიზაციის საშუალებას წაართმევს.