Skip to main content

Patch for Windows Server 2003 to accept multiple Sessions

 


Multiple Remote Desktop sessions Over Windows Server 2003

ينصح بأخذ ملف باك اب لاعادتة فى حالة فشل او حدوث ايه مشاكل
قدّمت عائلة ويندوز سيرفر 2003 طقماً متكاملاً بشكل مُحكم من الأدوات والتقنيات التي مكّنت Terminal Services للإدارة البعيدة ولمشاركة البرامج , لقد استمر ذلك النمو إلى أن أصبحت Terminal Services الآن مكوناً متمماً افتراضياً في عائلة ويندوز سيرفر 2003 .
إن العديد من التحسينات التي طرأت على مايكروسوفت ويندوز سيرفر 2003 لها علاقة بخدمات الدعم ووصلة سطح المكتب البعيد وذلك من خلال خدمات المحطة الطرفية (Terminal Services) التي تم تطويرها بشكل ملحوظ في ويندوز سيرفر 2003 , إلا أن هذه الخدمة تستطيع أن تستقبل افتراضياً 2 جلسة عمل (Session) , ولتجعلها تستقبل أكثر من Session عليك أن تشتري ترخيص من شركة مايكروسوفت الذي يكون عادةً سعره مرتفع قليلاً وخاصةً للمكاتب والشركات الصغيرة .

نقدم لكم اليوم Patch يقوم بكسر الخدمة Terminal Services ويجعلها تستقبل أكثر من جلسة عمل Session في نفس الوقت , ولكن يجب الانتباه إلى موضوع هام جداً وهو إصدارة الملف الذي سنقوم بكسره والمسؤول عن العملية كلها .

الملف termsrv.dll الذي قمنا بكسره والمسؤول عن العملية كلها هو للإصدارات 5.2.3790.3959 و 5.2.3790.1830 و 5.2.3790.2825 وتمت التجربة من قبلي على Windows Server 2003 x32 وبنجاح , لذلك يجب أن تتأكد من إصدارة الملف عندك قبل أن تقوم بتنفيذ الباتش .

كيف تعرف إصدارة الملف ؟؟؟

الجواب بسيط , اذهب إلى C:\Windows\System32 وابحث عن الملف termsrv.dll , ثم بالزر اليمين للماوس اختر Properties وانتقل للتبويب Version وستجد إصدارة الملف , لاحظ الشكل التالي :



بالنسبة لإصدارة الملف termsrv.dll Build 5.2.3790.0 فالحقيقة بعد كسر هذا الملف لهذه الإصدارة بالذات حدثت بعض المشاكل في الاتصالات , لذلك أنصح وبشدة ترقية ويندوز سيرفر وتنصيب آخر حزمة الخدمات Service Pack ثم بعد ذلك تنفيذ الباتش المناسب حسب الإصدارة بعد التحديث .



ملاحظة:
إذا قمت بتنفيذ الباتش على نسخة Windows Server 2003 SP1 ذات الإصدارة 5.2.3790.1830 termsrv.dll ثم بعد ذلك قمت بالترقية إلى Windows Server 2003 SP2 , فعليك إعادة تنفيذ الباتش للإصدارة الجديدة بعد التحديث وهي termsrv.dll 5.2.3790.3959 .


ملاحظة:
إذا قمت بتنفيذ الباتش على نسخة Windows Server 2003 SP1 ذات الإصدارة 5.2.3790.1830 termsrv.dll ثم بعد ذلك قمت بالترقية إلى Windows Server 2003 SP2 , فعليك إعادة تنفيذ الباتش للإصدارة الجديدة بعد التحديث وهي termsrv.dll 5.2.3790.3959 .




طريقة تنفيذ الباتش Patch :

1- أعد تشغيل جهاز السيرفر وادخل إلى الوضع الآمن Safe Mode .

2- قم بنسخ ملف الباتش إلى أي مكان تريده وليكن على سطح المكتب مثلاً , ثم قم بتنفيذه كما في الصورة :




3- اذهب إلى Run ثم اكتب gpedit.msc ثم أنتر .
4- اذهب إلى العقدة Computer Configuration > Administrative Templates > Terminal Services ثم اختر Limit Number of Connections واجعلها Enabled واختر الرقم 10 عند TS Maximum Connections Allowed , تابع الصور :






5- بعد أن تنتهي اذهب إلى Run ثم اكتب cmd ثم أنتر , سيفتح لك موجه الدوس اكتب فيه gpupdate /force ثم أنتر وهذا ليعمل Refresh لــ Group Policy ويحمّل التغييرات , ثم بعدها اعمل ريستارت للسيرفر وادخل بشكل عادي واستمتع بخدمة Remote Desktop بأكثر من 2 جلسة عمل .

أنصحك بعدم إدخال الكثير من المستخدمين عبر Remote Desktop وفتح أكثر من 10 Session بوقت واحد , لأن هذا سيضيف عبئ إضافي على السيرفر وقد يتسبب بحمل وبطئ ملحوظ وخاصةً أثناء أوقات الذروة , لذلك لو لاحظت لم أقم بوضع رقم أكبر من 10 عند TS Maximum Connections Allowed في الخطوة رقم 4 , وطبعاً يمكنك زيادة الرقم مثلما تتطلب الحاجة عندك وحسب طاقة السيرفر عندك ومواصفاته .


ملاحظة :
هذا الباتش خاص بــ Windows Server 2003 32bit ومجرب ويعمل بشكل صحيح

أتمنى أن أرى تجاربكم وتضعوا لنا صورة لجلسات العمل المفتوحة على سيرفراتكم كما التقطها أنا من على سيرفري بواسطة البرنامج Task Manager, وهذه هي الصورة :




طبعاً بعد تنفيذ الباتش سيصبح بإمكان السيرفر استقبال أكثر من 2 Session في نفس الوقت , وهذا يطبق أيضاً على أدوات HTML للإدارة البعيدة , يمكنك معرفة المزيد حول هذه الأدوات من خلال الموضوع التالي :






ختاماً , يمكنكم تحميل ملف الباتش من حسب إصدارة الملف
termsrv.dll
الموجود لديكم في نسخة ويندوز سيرفر .

Windows Server 2003 x32 Terminal Server Patch for (termsrv.dll) Build 5.2.3790.3959 & 5.2.3790.2825 :

http://www.4shared.com/file/W5NWiM3D...32_Termin.html


or

Windows Server 2003 x32 Terminal Server Patch for (termsrv.dll) Build 5.2.3790.3959 :

http://www.4shared.com/file/9BUKY5Ry...32_Termin.html

Comments

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

    Symptoms A VMFS-5 datastore is no longer visible in vSphere 5 datastores view. A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view. In the  /var/log/vmkernel.log  file, you see an entry similar to: .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks) A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the  /var/log/vmkernel.log  file you see an entry similar to: .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)   Purpose This article provides steps to correct the VMFS-5 partition table entry using  partedUtil . For more information see  Using the partedUtil command line utility on ESX and ESXi (1036609) .   Cause The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the ...