dedibox sc 2016 - windows 2016 - no access after deploy
I did deployed this image : Microsoft_Windows_Server_2016_Datacenter_Evaluation_64-bit_US_English.gz
I had impresion that's all things was good
[email protected]:~# wget -O- http://mirror.whatuptime.com/XXXXX/releases/Microsoft_Windows_Server_2016_Datacenter_Evaluation_64-bit_US_English.gz | gunzip | dd of=/dev/sda
Resolving mirror.whatuptime.com (mirror.whatuptime.com)... 188.8.131.52
Connecting to mirror.whatuptime.com (mirror.whatuptime.com)|184.108.40.206|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4596264608 (4,3G) [application/octet-stream]
Saving to: ‘STDOUT’
100%[====================================>] 4 596 264 608 26,8KB/s in 10m 45s
2017-09-08 12:17:09 (6,79 MB/s) - written to stdout [4596264608/4596264608]
31457280+0 records in
31457280+0 records out
16106127360 bytes (16 GB) copied, 655,813 s, 24,6 MB/s
But after i did passed in normal mode, I can't access by RPD to the sever. I did try to restart.... same result
I use the rescue mode and qemu and I can start the windows (in qemu). My impression is that the server, in normal mode, don't succeed to have DHCP IP...
Is there somedoby to help me 😉 ?
Template Name: Microsoft_Windows_Server_2016_Datacenter_Evaluation_64-bit_US_English.gz
Vendor Service Package: dedibox SC 2016
Physical or Virtual: Physical Server
Processor: Intel(R) Atom(TM) CPU C2338 @ 1.74GHz
Ethernet controller : Intel Corporation I210 Gigabit
Location: Online.net, France, DC5)
Error Information: After deployment : no access via RDP (try from different site, others servers still accessible via RDP)
With rescue mode (Ubuntu 14)
Qemu : wget -qO- /tmp https://ia601503.us.archive.org/12/items/vkvm.tar/vkvm.tar.gz | tar xvz -C /tmp
launch serveur in emulated mode : /tmp/qemu-system-x86_64 -net nic -net user,hostfwd=tcp::3389-:3389 -m 2048M -localtime -enable-kvm -cpu host,+nx -M pc -smp 2 -vga std -usbdevice tablet -k en-us -hda /dev/sda -boot c -vnc :1
With VNCviewer and public IP of the server, you can access to your server and view event log : Your computer was not assigned an adress from the network (by the DHCP Server) for the network Card with network address 0xmacadresse. The following error occurred: 0x79. Your computer will continue to try obtain an address on its own from the network address 5DHCP) server.
I had open a ticket at Online.net. They told mes that there are no problem on their infrastructure...
Where is the problem. Why this deployment image is not accessible ?
Unfortunately as it stands I do not have that answer available, however we are still actively troubleshooting with the intent of coming to a resolution.
As soon as we have any information to share, we will release it.
Apologies for in the unforseen issues.
Thanks to a generous member here I have had direct access to a SC SATA 2016 for the last few days allowing me direct access to an Online.net machine where the templates we provide fail to work as intended. I have spent countless hours troubleshooting at this stage and honestly I am truly at a loss as to the reasons for the problems being faced.
My research/troubleshooting thus far...
- The issue appears to be limited to the "SC SATA or SC SSD" in the personal range of dedicated servers provided by Online.net. I have confirmed the templates are working correctly on various other "XC SATA and XC SSD" servers.
- The templates successfully install Windows to the dedicated servers and Windows starts without error (It boots up correctly)
- The drivers for the Intel I210 NICs are properly included in the templates and the NIC's are being properly installed according to both the Windows event log and the device log (I booted the Windows installation via QEMU using rescue mode to review all logs).
- Upon Windows booting & NIC drivers being installed typically an IPv4 IP is assigned via DHCP from Online.net's network, however in the current case an IP is never assigned (This is quite unexpected, DHCP is working as expected on all other non-SC systems we tested).
- I have manually assigned the correct IP address to the NIC using Windows NETSH command via batch file and Task Scheduler. The IP is correctly assigned to the NIC, the server responds to ping (I disabled the Windows firewall completely), however I am unable to access to the server via RDP (Remote Desktop) as it hangs on "Securing Connection".
- In light of RDP failing to connect I installed both TeamViewer & VNC, both fail to connect even though the server responds to ping.
- When booting Windows via QEMU using Online.net's rescue mode all three connection methods work without issue (RDP, TeamViewer & VNC).
I am uncertain where to head from here, but I am continuing to troubleshoot as ideas come to me.
I have put manually IP (by scheduled task)
The server can ping an outside IP (220.127.116.11 by exemple)
When I Try to catch traffic with wrireshark. I can observe first exchange between client RDP and server
attach file RDP session with server in normal mode.
Thank you for this answer. No clue with the SC 2016 problem ?
Unfortunately I haven't a clue as to the cause of the underlying problem. A generous member here on the forums allowed me direct access to his non-working SC 2016 for over a week during which I spent countless hours attempting to resolve the issue, but unfortunately I made no progress at all.
The issue so far has only been experienced on SC 2016 server's with the Intel V210 NIC, all SC/XC 2016 server's with the Intel I350 NIC are working as expected.
The issue is either with the Intel V210 NIC (ie. Drivers) or a limitation in place on the Online.net network. The drivers report everything is operational and working as intended, however no matter the changes made network access is never accomplished. The IP for the server isn't being provided by DHCP either (odd for Online.net in my experience), however even when the IP is manually assigned to the NIC the issue is still present.
When I manually added the IPv4 IP to the NIC the server would respond to ping and RDP, however RDP would hang on "Securing Connection" and never completely connect. I had similar issues with both TeamViewer and VNC.
Something is whacked on the networking front.