Oooooo yes, finally working. All because I overlooked one file... see if you can guess which one from the instructions. So as I wrote previously, I had created a PE from HDD to RAM solution for cases where I was building a remote server that didn't have a virtual CDROM available but did have a virtual floppy available (for those familiar with HP server hardware, boxes with a RILOE / RILOE II).
But why bother with all that when you can just have a TFTP server and boot the WinPE ISO directly from there into the RAM of the server you are building! Here we go...
The following files are required, ALL from Windows PE 2005 / Windows Server 2003 + SP1. Yes I know you could use a PE ISO built from XP but with ramdisk.sys from 2003+SP1, but for the sake of brevity... oh well there goes that idea!
1. A Windows PE ISO, built from 2003 Server + SP1
2. startrom.com from the 2003 Server + SP1 CD
3. ntdetect.com from the PE ISO
4. winnt.sif, with the same entries as the PE HDD to RAM post
5. setupldr.exe from the PE ISO. !!!NOTE!!! That's SETUPLDR.EXE that is 272KB - NOT NOT NOT setupldr.bin which is 292KB in size. Rename SETUPLDR.EXE to NTLDR. The file size is 272KB. Did I mention it needs to be the SETUPLDR.EXE renamed to NTLDR?
OK, so follow the instructions in the previous post to setup your free Microsoft TFTP server.
Put the 5 files mentioned above into the TFTPROOT directory.
Set option 066 on your DHCP server, with a value of the IP address of your TFTP server.
Set option 067 on your DHCP server, with a value of startrom.com
*Note* If your DHCP server and TFTP server are the same box, you also need to set option 060 on the DHCP server to tell PXE Clients that port 67 on the DHCP server is also serving up PXE boot images. DHCP listens on port 67 by default.
And voila, that's it!
"But n0000000000dles...", I hear you say, "we don't have DHCP running in our datacenters so we can't PXE boot."
Well, I think you're outta luck, but I'll look around and see if I can find some other solution.
Monday, October 24, 2005
Friday, October 21, 2005
Running a Windows TFTP Server
There are several 3rd party free TFTP servers for Windows out there, but why use a 3rd party product when you already have a free TFTP server on the install CD? Lets roll!
First, grab the Windows Server 2003 resource kit, and install it.
Now open a shell and go to your I386 directory (CD or distribution share - doesn't matter).
Run expand tftpd.ex_ %systemroot%\tftpd.exe. Note you could place the .exe elsewhere if you like.
Still in the shell, change to the Windows 2003 reskit install directory and run instsrv tftpd %systemroot%\tftpd.exe.
Create a TFTP root directory. It can be anywhere and named anything. For example, D:\TFTProot.
Run the following commands to create / modify the appropriate registry values
reg add hklm\system\currentcontrolset\services\tftpd /v DisplayName /t REG_SZ /d "TFTP Server"
reg add hklm\system\currentcontrolset\services\tftpd\Parameters
reg add hklm\system\currentcontrolset\services\tftpd\Parameters /v Directory /t REG_SZ /d d:\tftproot
And finally, do a net start tftpd
And that's it. Of course it would be a good idea to set the appropriate NTFS permissions on the TFTP root directory, and run the service with a low privileged account.
Why am I doing this? I'm looking to take the 'PE from HDD to RAM' to the next level, which is booting PE via PXE :-)
First, grab the Windows Server 2003 resource kit, and install it.
Now open a shell and go to your I386 directory (CD or distribution share - doesn't matter).
Run expand tftpd.ex_ %systemroot%\tftpd.exe. Note you could place the .exe elsewhere if you like.
Still in the shell, change to the Windows 2003 reskit install directory and run instsrv tftpd %systemroot%\tftpd.exe.
Create a TFTP root directory. It can be anywhere and named anything. For example, D:\TFTProot.
Run the following commands to create / modify the appropriate registry values
reg add hklm\system\currentcontrolset\services\tftpd /v DisplayName /t REG_SZ /d "TFTP Server"
reg add hklm\system\currentcontrolset\services\tftpd\Parameters
reg add hklm\system\currentcontrolset\services\tftpd\Parameters /v Directory /t REG_SZ /d d:\tftproot
And finally, do a net start tftpd
And that's it. Of course it would be a good idea to set the appropriate NTFS permissions on the TFTP root directory, and run the service with a low privileged account.
Why am I doing this? I'm looking to take the 'PE from HDD to RAM' to the next level, which is booting PE via PXE :-)
Wednesday, September 28, 2005
Weighing in on the Google vs Microsoft thing...
There seems to be a *lot* of conjecture going on regarding Google extending it's reach into the home by offering some kind of client... maybe an OS. There are a lot of comments along the lines of 'the internet has matured enough now' and 'the network is the computer' etc etc. And most of all 'is this the end of Microsoft?'.
Let me just say LOL! What are these people taking (and where can I get some ;-). If someone was serious enough to think that Google was going to make some kind of thin client based foray into the OS market, maybe even combined with some kind of hardware offering, they should also consider what Microsoft currently offers /has in the pipeline in this space. Namely
1) The existing Windows Embedded product
2) The upcoming Eiger thin client
3) Terminal Services, both in it's current form and the upcoming Longhorn version (which will be offering things like seamless applications, which Citrix has had for at least 10 years)
4) Exchange / Outlook Web Access, Sharepoint
5) MSN
And on top of that, consider what Microsoft would have to gain by competing with Google in terms of a 'managed service' offering. Very few software companies have piracy problems on the scale that Microsoft does. If Microsoft could drop development of a full blown OS tomorrow and only offer a thin client solution that cost little or nothing and host a bunch of services on the backend that people paid for on a subscription basis, they would be more profitable than they are now. Not only would their payroll be cut in half, so would their R&D, their support costs and their security headache (and associated image problems) would verge on disappearing.
But is Microsoft heading in this direction? Of course not. If they were, what would the likes of Intel, AMD, Creative, nVidia, ATI, Seagate, Maxtor, Samsung, Hynix, Dell, HP and all the other massive hardware companies out there do about it? Probably switch to Linux :-P. Seriously though, these hardware companies benefit so much by having Microsoft add features that require more CPU, more RAM, more disk, better graphics etc etc. The last thing they would want to see would be a massive swing to thin client or appliance based computing. There's certainly no way the likes of Dell or anyone else would entertain manufacturing a low cost, low margin thin client for Google. I can see Steve Ballmer's reaction now. I suppose Google could try to make a go of hardware manufacturing alone, but it would be a brave, expensive gamble.
I'll be interested to look back on this in a few years time.
Let me just say LOL! What are these people taking (and where can I get some ;-). If someone was serious enough to think that Google was going to make some kind of thin client based foray into the OS market, maybe even combined with some kind of hardware offering, they should also consider what Microsoft currently offers /has in the pipeline in this space. Namely
1) The existing Windows Embedded product
2) The upcoming Eiger thin client
3) Terminal Services, both in it's current form and the upcoming Longhorn version (which will be offering things like seamless applications, which Citrix has had for at least 10 years)
4) Exchange / Outlook Web Access, Sharepoint
5) MSN
And on top of that, consider what Microsoft would have to gain by competing with Google in terms of a 'managed service' offering. Very few software companies have piracy problems on the scale that Microsoft does. If Microsoft could drop development of a full blown OS tomorrow and only offer a thin client solution that cost little or nothing and host a bunch of services on the backend that people paid for on a subscription basis, they would be more profitable than they are now. Not only would their payroll be cut in half, so would their R&D, their support costs and their security headache (and associated image problems) would verge on disappearing.
But is Microsoft heading in this direction? Of course not. If they were, what would the likes of Intel, AMD, Creative, nVidia, ATI, Seagate, Maxtor, Samsung, Hynix, Dell, HP and all the other massive hardware companies out there do about it? Probably switch to Linux :-P. Seriously though, these hardware companies benefit so much by having Microsoft add features that require more CPU, more RAM, more disk, better graphics etc etc. The last thing they would want to see would be a massive swing to thin client or appliance based computing. There's certainly no way the likes of Dell or anyone else would entertain manufacturing a low cost, low margin thin client for Google. I can see Steve Ballmer's reaction now. I suppose Google could try to make a go of hardware manufacturing alone, but it would be a brave, expensive gamble.
I'll be interested to look back on this in a few years time.
Sunday, September 04, 2005
Tech.Ed 05 thoughts...
Since this was my first Tech.Ed, I don't have anything to compare it with, but I'm a little disappointed. The highlights were pretty much limited to the sessions from Steve Riley and Jesper Johanssen. But if you've been listening to them speak or reading their whitepapers / blogs and anything else over the past 2-3 years, it wasn't anything new. Especially not if you read their book before going!
But one huge highlight was the half hour 1 on 1 I had with Steve Riley. It seems he is at the same point I am with regards to Windows security, in that nowadays the problem is less technical and more people / process related. I think most Windows admins know what needs to be done to secure their boxes, and what technologies are available to keep them secure. But when it comes to getting outages from business owners, we're still in the same (bad) situation we were in 3 years ago.
Anyone who works in a large environment knows this. People who have only ever worked in small environments will have no idea of what I'm talking about. I'm not longer tolerant of people making flippant remarks about 'how come all the big enterprises get [insert attack here] - don't they know how to patch?'. Yeh right. You try getting an outage on a box that sees hundreds of millions of income go through it. It doesn't matter if it's clustered - business people are paranoid of any change, esepcially when it's something they do not understand and there's a LOT of money involved.
Steve mentioned he is working on a presentation about showing security ROI. I can't wait to get his thoughts on that, not that I'm waiting for him to do something... all Windows admins should be looking into this asap!
But one huge highlight was the half hour 1 on 1 I had with Steve Riley. It seems he is at the same point I am with regards to Windows security, in that nowadays the problem is less technical and more people / process related. I think most Windows admins know what needs to be done to secure their boxes, and what technologies are available to keep them secure. But when it comes to getting outages from business owners, we're still in the same (bad) situation we were in 3 years ago.
Anyone who works in a large environment knows this. People who have only ever worked in small environments will have no idea of what I'm talking about. I'm not longer tolerant of people making flippant remarks about 'how come all the big enterprises get [insert attack here] - don't they know how to patch?'. Yeh right. You try getting an outage on a box that sees hundreds of millions of income go through it. It doesn't matter if it's clustered - business people are paranoid of any change, esepcially when it's something they do not understand and there's a LOT of money involved.
Steve mentioned he is working on a presentation about showing security ROI. I can't wait to get his thoughts on that, not that I'm waiting for him to do something... all Windows admins should be looking into this asap!
Thursday, August 18, 2005
Clustering with VMWare 5.x...
Contrary to most things you'll read, it actualy is possible to share disks in VMWare 5.x. So now you don't have to have 3 VM's with one being an iSCSI host to do clustering. The trick is to create your primary OS disks as IDE drives, use vdiskmanager to create a SCSI based disk for the quorum, then add the following lines to the .vmx files of the servers you want to cluster:
disk.locking=FALSE
scsi0:0.present = "TRUE"
scsi0:0.fileName = "..\wherever_disk_is_stored\QUORUM.vmdk"
scsi0:0.redo = ""
scsi0:0.mode = "independent-persistent"
scsi0:0.deviceType = "disk"
Then follow the normal cluster build process. The cluster service will ensure you don't get both nodes trying to write to disk at once.
disk.locking=FALSE
scsi0:0.present = "TRUE"
scsi0:0.fileName = "..\wherever_disk_is_stored\QUORUM.vmdk"
scsi0:0.redo = ""
scsi0:0.mode = "independent-persistent"
scsi0:0.deviceType = "disk"
Then follow the normal cluster build process. The cluster service will ensure you don't get both nodes trying to write to disk at once.
Subscribe to:
Posts (Atom)