Let me start off with a warning about this exam.
This test is not available everywhere, and for good reason. It is a complicated exam which launches a Real Virtual Lab environment which is run off of a server across the Internet.
The key word there being "Internet", which this often implies not having Routing issues, connection problems, speed, latency (Lag) and other client to server remote connection issues.
Lets just say, I ran into some of those issues – And you might as well. I went in with an expectation to potentially have some problems. Exam launched, Click connect to visit the lab and BAM – no connection. 3 hours later of them ‘resetting the exam‘ I was then able to connect into the server. Sadly I did not have the amount of time to fully take advantage of the exam, but I did have the opportunity to read, review and comment.
The labs are interesting, it’s a true server (help files and all) and command line and other decisions and exploitations and choices you’d make on a server host. But beware.
I encountered all that I mentioned, lag, connection issues, delay, and a slew of other ‘technical’ issues which can happen to anyone. Great exam for what it is worth (and I commented away based upon the content and delivery) But do approach this Pilot with an expectation that you MAY encounter issues. Prometric CAN work them out, but the Helpdesk will likely have no idea what is going on and what to do (Hopefully this 3 hour ‘lesson’ will prepare them for the next person who takes it)
Good luck, and Good Testing!
Tags: 70-113, beta, certification, exam, Performance, Pilot, Server 2008, Simulation, Virtual Lab, windows server 2008
Posted in Baltimization, Certification, Christopher Kusek, Informational, Microsoft, Windows Server | Comments (2)
As a security guy, I can tell you – There are a lot of really good security best practices to be applied across all systems, applications, servers and a world over. But when implemented unchecked – Problems will arise.
What I am talking about specifically is this little doozy – EnablePMTUDiscovery
Value name: EnablePMTUDiscovery
Key: Tcpip\Parameters
Value Type: REG_DWORD
Valid Range: 0, 1 (False, True)
Default: 1 (True)
The following list describes the parameters that you can use with this registry value:
1: When you set EnablePMTUDiscovery to 1, TCP attempts to discover either the maximum transmission unit (MTU) or then largest packet size over the path to a remote host. TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs by discovering the path MTU and limiting TCP segments to this size. Fragmentation adversely affects TCP throughput.
0: It is recommended that you set EnablePMTUDiscovery to 0. When you do so, an MTU of 576 bytes is used for all connections that are not hosts on the local subnet. If you do not set this value to 0, an attacker could force the MTU value to a very small value and overwork the stack.
Important Setting EnablePMTUDiscovery to 0 negatively affects TCP/IP performance and throughput. Even though Microsoft recommends this setting, it should not be used unless you are fully aware of this performance loss.
That little excerpt taken from:
How to harden the TCP/IP stack against denial of service attacks in Windows 2000
This KB article is still used and is applicable to the Windows 2003 space, but what does this do exactly?
This will drop all transmissions over TCP/IP down to 576 byte packets. Oh and this is a global setting.
So, you go to connect up to an iSCSI LUN, and it connects up just fine.
Your host is working, your storage is working everything is all doozy.
When you start to try to actually -use- that connection for storage though, you’ll begin to experience exponential latency. This latency will translate into IOPS problems and access to the disk, masking this making it appear to be a disk issue. This effectively cripples your application, yet is hidden so well from the system as a problem without sniffing or using something like mturoute you’d never know it is happening.
MTURoute is your friend and will help you determine your current MTU
With that said, on any systems with iSCSI connectivity, I strongly encourage you to NOT disable this setting, ensuring that EnablePMTUDiscovery is always set to 1
Thanks for your time!
Tags: 2000, 2003, EnablePMTUDiscovery, IOPS, iscsi, luns, mturoute, Performance, Windows Server
Posted in Baltimization, Christopher Kusek, Informational, Microsoft, NetApp, SQL, Storage, Windows Server | Comments (5)
