Sunday, October 18, 2009

Hyper-V Workgroup Mode How To

1. Install “Remote Server Administration Tools” for Windows 7 from http://www.microsoft.com/downloads/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en

2. Navigate to Start > Control Panel >Programs > Turn Windows Features On or Off.

3. Select the Hyper-V Tools

4. Click OK for it to install these tools under Start > Administrative Tools

5. Add a CNAME for your server in c:\windows\system32\drivers\etc\hosts

6. On the server, enable “MMC Remote Management”

7. Also enable remote desktop, to make it easier to connect to the server console if settings need to be changed. This is option 7 in the main menu on the screen above.

8. Add a Local Administrator with the same user name as the account on the Windows 7 Client machine. This is option 3 in the main menu on the screen above.

9. Preferably, set a static IP address for the server, to make it easier to find it every time you need to manage it. This is under option 8 in the main menu on the screen above.

10. Run the following commands on the server

a. netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes

b. net localgroup "Distributed COM Users" /add “username” (without quotes)

11. Run the following commands in an Administrative Mode Command Prompt on the Windows 7 Client machine.

a. netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes

b. netsh firewall add allowedprogram program=%windir%\system32\mmc.exe name="Microsoft Management Console

c. net localgroup "Distributed COM Users" /add “username” (without quotes)

12. Launch the Component Services mmc snapin and navigate to Component Services > Computers > My Computer > Right Click > Properties.

13. Under the COM Security tab, select Edit Limits under Access Permissions

14. Enable Remote Access for Anonymous Logon

15. Launch the Hyper-V Management Console and add the server you just provisioned.

Sunday, September 27, 2009

Linksys WRT54G2 Port Connections Matter

I was always under the impression that Linksys made some of the best routers around - primarily because they were -

1. Utterly dependable
2. Consistent in their operation
3. Work Fast

Well today, one of these isn't valid anymore - point 2.

It turns out that the ports behind the WRT54G2 (I have version 1) also define the speed that you get when you transfer data with the WAN modem. All along I had connected my PC to PORT 1 and used to get 1 MBit/sec, which is what I paid for.

Last month though, I did a bit of housekeeping in the den and connected the PC to port 4. I didn't notice that the speed had gone down to 250 kbits /sec until last week and was obsessing over it with pings and traceroutes... When I put 2 and 2 together and connected it to Port 1 - back to 1 Mbits /sec again...

Man, fighting shadows like this sure is tiring; but thankfully, the net is back baby!

Sunday, March 29, 2009

VMware virtual networks sure are squeamish

I run a few heavy machines in VMs and have, for the most part, found it to be an excellent environment that practically guarantees isolation and provides administrators with a safety net that keeps them from ripping their hair out. But there are a few gotchas, and this one relates to bridged adapters.

Apparently, upgrading from VMware workstation 6.0 to 6.5 isn't guaranteed to work out of the box for Linux VMs. When the upgrade is complete, the Linux VMs fail to get IP addresses from the DHCP server. It turns out that a service called VMware Bridge Protocol that should be active on all physical Ethernet adapters, isn't working correctly. If it is removed and added manually, windows VMs get bridged just fine; but Linux VMs don't.

So, after a whole days of pulling my hair out, I figured I'd try rolling back the mess and guess what? Re-Installing workstation 6.0 gets the bridge protocol added automatically this time; but the linux vms were still off the wire! After wondering again, if it is the paravirtual kernel playing havoc with vmware's broken bridging protocol, I tried changing the network settings from being bridged, to manually using vmnet 0 and viola! The chatter on the wire is back on.

Of course, before selecting vmnet 0, I had to open the vmware virtual network editor and force it to not bridge automatically to a physical adapter, and then select vmnet 0 to use the Intel 10/100 ethernet adapter manually.

Yeah, this smells of some rotten fish; but hey, it sure beats running 15 physical servers eating away at the electricity and having to set up a freakish physical network to get em all running up to speed. I should begin looking into installing VMWare ESXi to isolate windows scruffles from these tailspins; but wonder if its worth it...

Sunday, March 22, 2009

Razer's Laws of software development

Basic truths and best practices for software development


1. There is no substitute for good development practices; no API in the world can make badly written code work well.

2. Write good software from the ground-up. Dependence on APIs that haven't been optimized will only result in fatter, slower code. The more there is focus on feature-addition on these APIs, the lesser inclined someone will be to go back and optimize them.

3. Focus on applying ONLY what is necessary to get the job done. There is no need to get a JIT, GC and a full runtime spooling up just to make a math calculation.

4. Focus on spreading complexity, not aggregating it. Modularity is your friend. Make it easy for someone to rip out what they think is inefficient and use a better module in your application.

5. Managers and users will never understand software development paradigms. Don't waste time forcing them to see your way. They see reliability, simplicity, cost and ease of use. Sell good software based on these factors.

6. Restrictions are your friend. Do not code apps that do everything at once. Users really want simple workflows. If your app has the features, but doesn't deliver the simple workflow; it won't be used.

Nuggets


1. What is simple, will scale well.
2. What is easy (to understand, to use), will be optimized more frequently by more people.
3. What is reliable will be used more often.