Including TFS (and some other features) in MSDN Pro has another benefit: it makes it possible to use these features when working with offshore outsourcing partner. It is no secret, that offshore development is all about cost, so to keep the cost down the offshore partners limit the money they are willing to pay for development tools. Having extra $2000 per developer means extra 96c per hour, which can reach 5% of the hourly rate. Which means that either the company risk losing business or the developer will be underpaid.
So this is really a smart move from Microsoft side.
Thursday, April 29, 2010
Wednesday, April 28, 2010
Overheard today...
A manager about the consulting company he uses for software development:
"I don't like them to be creative. We are not paying them to be creative."
"I don't like them to be creative. We are not paying them to be creative."
Tuesday, April 27, 2010
Why Non-broadcast Networks are not a Security Feature
http://technet.microsoft.com/en-us/library/bb726942.aspx
Wireless security consists of two main elements: authentication and encryption. Authentication controls access to the network and encryption ensures that malicious users cannot determine the contents of wireless data frames. Although having users manually configure the SSID of a wireless network in order to connect to it creates the illusion of providing an additional layer of security, it does not substitute for either authentication or encryption.
A non-broadcast network is not undetectable. Non-broadcast networks are advertised in the probe requests sent out by wireless clients and in the responses to the probe requests sent by wireless APs. Unlike broadcast networks, wireless clients running Windows XP with Service Pack 2 or Windows Server® 2003 with Service Pack 1 that are configured to connect to non-broadcast networks are constantly disclosing the SSID of those networks, even when those networks are not in range.
Therefore, using non-broadcast networks compromises the privacy of the wireless network configuration of a Windows XP or Windows Server 2003-based wireless client because it is periodically disclosing its set of preferred non-broadcast wireless networks. When non-broadcast networks are used to hide a vulnerable wireless network—such as one that uses open authentication and Wired Equivalent Privacy—a Windows XP or Windows Server 2003-based wireless client can inadvertently aid malicious users, who can detect the wireless network SSID from the wireless client that is attempting to connect. Software that can be downloaded for free from the Internet leverages these information disclosures and targets non-broadcast networks.
This behavior is worse for enterprise wireless networks because of the number of wireless clients that are periodically advertising the non-broadcast network name. For example, an enterprise wireless network consists of 20 wireless APs and 500 wireless laptops. If the wireless APs are configured to broadcast, each wireless AP would periodically advertise the enterprise’s wireless network name, but only within the range of the wireless APs. If the wireless APs are configured as non-broadcast, each of the 500 Windows XP or Windows Server 2003-based laptops would periodically advertise the enterprise’s wireless network name, regardless of their location (in the office, at a wireless hotspot, or at home).
For these reasons, it is highly recommended that you do not use non-broadcast wireless networks. Instead, configure your wireless networks as broadcast and use the authentication and encryption security features of your wireless network hardware and Windows to protect your wireless network, rather than relying on non-broadcast behavior.
Wireless security consists of two main elements: authentication and encryption. Authentication controls access to the network and encryption ensures that malicious users cannot determine the contents of wireless data frames. Although having users manually configure the SSID of a wireless network in order to connect to it creates the illusion of providing an additional layer of security, it does not substitute for either authentication or encryption.
A non-broadcast network is not undetectable. Non-broadcast networks are advertised in the probe requests sent out by wireless clients and in the responses to the probe requests sent by wireless APs. Unlike broadcast networks, wireless clients running Windows XP with Service Pack 2 or Windows Server® 2003 with Service Pack 1 that are configured to connect to non-broadcast networks are constantly disclosing the SSID of those networks, even when those networks are not in range.
Therefore, using non-broadcast networks compromises the privacy of the wireless network configuration of a Windows XP or Windows Server 2003-based wireless client because it is periodically disclosing its set of preferred non-broadcast wireless networks. When non-broadcast networks are used to hide a vulnerable wireless network—such as one that uses open authentication and Wired Equivalent Privacy—a Windows XP or Windows Server 2003-based wireless client can inadvertently aid malicious users, who can detect the wireless network SSID from the wireless client that is attempting to connect. Software that can be downloaded for free from the Internet leverages these information disclosures and targets non-broadcast networks.
This behavior is worse for enterprise wireless networks because of the number of wireless clients that are periodically advertising the non-broadcast network name. For example, an enterprise wireless network consists of 20 wireless APs and 500 wireless laptops. If the wireless APs are configured to broadcast, each wireless AP would periodically advertise the enterprise’s wireless network name, but only within the range of the wireless APs. If the wireless APs are configured as non-broadcast, each of the 500 Windows XP or Windows Server 2003-based laptops would periodically advertise the enterprise’s wireless network name, regardless of their location (in the office, at a wireless hotspot, or at home).
For these reasons, it is highly recommended that you do not use non-broadcast wireless networks. Instead, configure your wireless networks as broadcast and use the authentication and encryption security features of your wireless network hardware and Windows to protect your wireless network, rather than relying on non-broadcast behavior.
Wednesday, April 21, 2010
MSDN
Am I the only one who is confused by MSDN download screen? I have two MSDN subscription on my email, and I have no idea which software belongs to which client. I hope I don't get punished by Microsoft.
Tuesday, April 20, 2010
UPS
Just connected my server to APC UPS I just received. I realized that WHS does not have USB support, and the server itself does not have COM ports, and APC does not have a server version of the software that take care of shutdown. Oops...
This means I'll have to shutdown the server manually if I loose power for extended periods. Luckily that almost never happens. Most of the time I lose power for a few seconds, and the UPS should cover that.
This means I'll have to shutdown the server manually if I loose power for extended periods. Luckily that almost never happens. Most of the time I lose power for a few seconds, and the UPS should cover that.
Subscribe to:
Posts (Atom)