Hy all,

there is a news from connect...

Microsoft® Enterprise Desktop Virtualization (MED-V) enables deployment and management of Microsoft Virtual PC to address key enterprise scenarios, primarily resolving application compatibility with a new version of Windows.

 

Microsoft Enterprise Desktop Virtualization (MED-V) removes the barriers to Windows upgrades by resolving application incompatibility with Windows Vista or Windows 7.  MED-V delivers applications in a Virtual PC that runs a previous version of the operating system (for example, Windows XP).  And it does so in a way that is completely seamless and transparent to the user. Applications appear and operate as if they were installed on the desktop, so that users can even pin them to the task bar.  For IT administrators, MED-V helps deploy, provision, control, and support the virtual environments.

 

Microsoft Enterprise Desktop Virtualization is an integral tool in the Microsoft Desktop Optimization Pack, a dynamic solution available to Software Assurance customers that helps reduce application deployment costs, enable delivery of applications as services, and better manage and control enterprise desktop environments. 

 

MED-V 1.0 SP1 will add host support for Windows 7 (32bit and 64bit) and will be released in the first quarter of calendar year 2010.
Similarly to MED-V 1.0, MED-V 1.0 SP1 will leverage Microsoft Virtual PC 2007 to provide an enterprise solution for Application compatibility, and enabling the deployment of Virtual PCs across the enterprise.

cheers

Alex

 

The team of Windows 7 have announced that RTM version of Windows XP mode, which will use the new version of Windows Virtual PC and will allow users with Windows 7 to run a virtual machine with Windows XP usable to solve any problems. RTM of Windows XP Mode will be available at 22th October.

This is a great news for all users of Windows 7 that want to use legacy application on Windows XP.

Read more at Windows Blog HERE...

Dear all,

I would report a great new the you can read on left widget on my Blog...

The Microsoft Exchange Team has just announced that Exchange 2010 is now code complete and released to manufacturing. This means that Exchange 2010 is on schedule for general availability in early November. For more on this milestone announcement, see...(read more)

Wow all,

I am very happy to share that Windows Storage Server 2008 with the Microsoft iSCSI Software Target 3.2 is now available to all MSDN and TechNet Plus subscribers.

This Microsoft product should be offered via our OEM partners, but a version for evaluation (TechNet Plus or MSDN), is now being provided to MSDN and TechNet Plus subscribers for the first time. This opens the door for a number of interesting scenarios, especially when related to Windows Server Failover Clustering and/or Hyper-V.

Read all the post on JOSE BARRETO'S BLOG

thanks Jose!

Alex

 

All, how I've wrote in my precedent post 7 days ago (http://blog.caloni.net/post/1207080701/Windows+7:+Ready+RC+from+Technet+and+MSDN…+and+within+5th++may+for+all#more), technet Italy confirm that Windows 7 will be released through official channel (MSDN and TechNet) on the web within the end of April and for all at 5th may

here there is the link (italian)

http://blogs.technet.com/italy/archive/2009/04/27/windows-7-release-candidate.aspx

stay updated and stay connected

cheers

Alex

The Hyper-V role enables you to create a virtualized server computing environment using a technology that is part of the Windows Server® 2008 operating system.

 

The Failover Clustering feature enables you to create and manage failover clusters. A failover cluster is a group of independent computers that work together to increase the availability of applications and services. The clustered servers (called nodes) are connected by physical cables and by software. If one of the cluster nodes fails, another node begins to provide service (a process known as failover). Users experience a minimum of disruptions in service.

 

This Microsoft’s guide shows you how to use these two technologies together to make a virtual machine highly available. You will do this by creating a simple two-node cluster and a virtual machine, and then failing over the virtual machine from one node to the other.

Download Document HERE....

DHCP makes the life of a network administrator easier by automating the process of assigning IP address information to clients on your network. (Servers should generally have static addresses instead of dynamic ones.) However, using DHCP on your network introduces a point of failure--for what if your DHCP server suddenly dies?

 

With Windows 2000 and later this can be a problem because if the machine is configured as a DHCP client and its lease expires, it tries to renew its lease by communicating with a DHCP server on the network. If no DHCP server can be found, however, the client uses Automatic Private IP Addressing (APIPA) to auto-assign itself an IP address from the reserved address range 169.254.0.0 to 169.254.255.255. And when this happens, the client can no longer communicate with other machines on the network unless they have addresses from the same range. This is a good reason why you should disable APIPA on your Windows 2000 or Windows XP client machines, if you plan on using DHCP on your network.

 

Because DHCP servers are so important for ensuring network communications, however, it's also a good idea to take measures to ensure their availability. To begin with, this means using high-availability hardware platforms that have RAID 0+1, hot swappable drives and power supplies, and other forms of hardware fault tolerance for your DHCP servers. This way if a power supply dies or a drive fails, you can have your DHCP server up and running again in minutes. The moral is don't skimp on hardware costs for servers that your whole network depends on.

 

Clustering might seem like another option, but you have to be careful here. A Windows 2000/2003 clustered DHCP server is considerably more complicated to set up than a standard DHCP server, and the hardware requirements are higher as well. Additionally, not many companies can afford the resources to dedicate a server cluster to the simple job of leasing IP addresses for their network.

 

Forget 80/20

 

A common method for ensuring DHCP server availability is to install two DHCP servers on your network and use something called the 80/20 rule. The idea behind this rule is as follows:

 

• DHCP server 1 has its scope configured to lease 80 percent of your available IP addresses (for example, 10.0.0.1 to 10.0.0.200).

   

• DHCP server 2 has its scope configured to lease the remaining 20 percent of your addresses (10.0.0.201 to 10.0.0.250).

   

Next, you make sure that the available addresses on server 1 are sufficient for all DHCP clients on the local subnet, and place server 2 on a neighboring subnet. When a client tries to renew its lease by sending out a DHCP Renew message, this message typically reaches the DHCP server on the local subnet (server 1) first, but if server 1 is down then the DHCP server on the other subnet (server 2) can act as backup (provided your router is configured for BOOTP forwarding so it acts as a DHCP relay agent to pass DHCP broadcast traffic from one subnet to the next). For the other subnet you do the opposite; that is, server 2 provides 80 percent of the addresses for the subnet it resides on and server 1 provides 20 percent for the same subnet. The idea behind splitting the addresses 80/20 is because the 80 percent of addresses is normally sufficient for all the addresses needed on a subnet, and DHCP leases are typically three days, so if your subnet's main DHCP server goes down for a few hours then it's unlikely that more than 20 percent of the machines on that subnet will need to renew their addresses during the downtime, making the 20 percent pool of addresses sufficient.

 

That holds true unless it takes longer than a few hours to get your failed DHCP server working again (for example, if it fails just after working hours and your network monitoring software fails to beep you on your pager). Or unless you've configured leases shorter than three days because your network is a classroom, a conference facility, or has a lot of mobile users who connect to it remotely. Because of considerations like these, many network administrators prefer a more conservative 50/50 rule, which actually works even better in a single subnet environment anyway, provided both servers have enough addresses scoped to cover the needs of all the clients on the network. Then if one server goes down, the other one can take up the slack for as long as it takes to get the first one up and running again. The typical way of implementing this is to use exclusions, for example:

 

Server 1

 

Scope 10.0.0.1 to 10.0.0.250

 

Exclusion 10.0.0.126 to 10.0.0.250

 

 

Server 2

 

Scope 10.0.0.1 to 10.0.0.250

 

Exclusion 10.0.0.1 to 10.0.0.125

 

But you can also simply configure the scopes separately as:

 

Server 1 scope 10.0.0.1 to 10.0.0.125

 

 

Server 2 scope 10.0.0.126 to 10.0.0.250

 

Just don't let the scopes overlap when you configure them.

 

Other Solutions

 

If you're really paranoid about DHCP availability on your network, you can also configure a third DHCP server that mirrors the configuration of your 80 percent server, if you're using the 80/20 rule, or one of your 50 percent servers, if you're using 50/50. Once you've configured this server, however, keep it disconnected from the network as a hot backup DHCP server. Then if your main DHCP server goes down you can bring the backup one online to take its place. In this scenario you might ask, "Why keep the 20 percent server if you have a hot backup?" The reason is, what if your 80 percent server dies during the night and you're not around to flip the switch and connect your backup to the network? Unless you have sophisticated network management software that can handle this situation by bringing your spare 80 percent server online, some of your clients may be out of luck if they want to connect to the network before morning comes.

 

Here's another interesting approach: configure both DHCP servers on your network with identical scopes. Now, normally this would cause problems because you might end up having the same address leased by both servers, causing clients to hiccup. However, if you enable address conflict detection on your DHCP servers and set it to 2, then each DHCP server will test an address three times to make sure it's not already being used before leasing it to a client, and this will prevent one server from leasing an address that the other server has already leased. The only downside to this approach is that it will make DHCP traffic on your network a bit more noisy, but DHCP traffic is so minimal anyway this will have only marginal impact on overall network performance. But why not set this to one attempt instead of two attempts? Safety--you don't want a network glitch that causes brief packet loss to ruin your setup. To configure address conflict detection on a Windows 2000 DHCP server use the Advanced tab of the properties sheet for the server in the DHCP console (Figure 1):

Figure 1. Configuring address conflict detection on a DHCP server

 

Finally, a setup some companies prefer is to use DHCP but create a reservation for each and every client machine on the network. That way, whenever a client leases an address using DHCP it always receives the same address from the DHCP server. How is this different from static addressing? Well, for one thing, you don't have to walk around to every machine on your network and manually configure its IP address settings. Instead, you can do it centrally on your DHCP server, provided you know the MAC addresses of every client on your network. One way of doing that is to begin by configuring your DHCP server with no reservations and let it lease out addresses to all the clients on your network. Then run the netsh dhcp dump command on your DHCP server to dump the DHCP database, which gives you the IP address and MAC address of each client machine. Then, with a little ingenuity, you could write a script that uses the netsh dhcp add reservedip command to take your dumped DHCP database and create reservations for all your clients using the presently leased IP addresses. Of course, if you want clients to have specific IP addresses instead of a randomly assigned one, then you've got a lot more work ahead of you!

 

Why on earth would anyone want to use this all-reserved approach? Better security. Since each client always has the same IP address, it's easier to interpret address information in your firewall logs. And since you're still using DHCP you can easily make changes to your default gateway and other TCP/IP settings, and you can do this without opening up the possibility of clients changing their addresses in the process. Finally, ensuring clients always have the same address makes it easier to track the Internet usage of each user, if your company has a policy that requires this to be done.