Massimo's questions

Windows 8 / 8.1 / 10 has this feature called "Fast Startup" (or "fast boot", "hybrid statup", "hybrid shutdown", and so on...) which doesn't actually shut down the computer when you tell it to do so, instead putting it in a sort of hybernation, in order to speed up boot time.

Although this might seem nice at first view, it has several known and ugly side effects:

• It can seriously screw up on some systems (possibly when using old/incompatible drivers or BIOSes), resulting in a system crash at boot time and a subsequent forced full boot (this I witnessed personally on several different systems... and good luck if you are also using mirrored dynamic disks, which will always undergo a full resync after a system crash).
• It does hell to the processing of some group policies, which require an actual system restart in order to be applied.
• Last but not least, it has been known to render Wake-On-Lan unusable; this is the problem I'm currently facing after an upgrade to Windows 10 of several Windows 7 PCs which used to WOL quite fine, and now just don't anymore.

For these and other reasons, I'd like to be able to manage Fast Startup using Group Policies; however, the only policy I could find about this (Computer Configuration\Policies\Administrative Templates\System\Shutdown\Require use of fast startup) can only be used to force the use of Fast Startup, but not to disable it: its description explicitly states that if you disable or do not configure this policy setting, the local setting is used.

Thus, my question: how can I disable Fast Startup using a group policy?

I've stumbled upon a strange behaviour with Windows machines, which seems to be fairly consistent between all Windows versions from Vista/2008 to 8.1/2012 R2; it doesn't happen instead when using Windows XP or Windows Server 2003.

The problem is this: when the network adapter is configured for DHCP and the DHCP server doesn't register DNS records on behalf of its clients (because it can't, or because it's not configured to do so), then the forward A record gets registered, but the reverse PTR record doesn't.

Some more details:

• Both the forward and the reverse DNS zones are AD-integrated and accept dynamic updates.
• All computers are joined to the domain.
• All computers use the correct internal DNS servers, both when configured statically and when getting their configuration from DHCP.
• "Register this connection's addresses in DNS" is enabled in the network adapters.
• Everything is fine when a computer has a static IP address; both the forward and the reverse records get automatically registered.
• When the same computer is configured for DHCP, the forward record is registered, but the reverse record isn't.
• This happens for all computers with an OS version >= 6.0, and it's definitely not related to a single machine.
• No amount of ipconfig /registerdns will change anything.
• No errors are logged anywhere.

Why does this happen, and how can it be fixed?

And no, configuring the DHCP server to perform DNS registration is not an option here.

I know from direct personal experience that disabling the Windows Firewall service on post-XP systems can lead to all sorts of networking problems, and that the proper way of disabling it is by configuring it to not block any traffic, yet leaving the actual service running. This is because from Vista onwards the Windows Firewall service is a critical component of the Windows networking stack, and stopping it will wreak havoc in completely random ways.

However, I keep stumbling upon people who think that just stopping and disabling the service is a fine solution, and that taking your time to properly disable it is simply too much unneeded work. Then, when all sorts of network pains ensue, they just won't acknowledge the real reason, and will try anything else before grudgingly accepting that, yes, maybe that service should be really left running.

Apart from hitting those people with heavy (and/or sharp) objects, the real solution here would be an official document stating "don't disable this service or you are just asking for troubles". And yet, the only post on this topic I was able to find simply says that "stopping the service associated with Windows Firewall with Advanced Security is not supported by Microsoft", which just doesn't look threatening enough to stop them from doing idiotic things.

Is there anything better I can refer to in order to back up my claim that the Windows Firewall service should indeed NOT be stopped?

A bit of clarification: I was actually not referring to users, but to admins with too much attitude and too little real knowledge, who think the above-described configuration is Just Right, implemented it via GPOs on their whole network, and are simply not listening when I tell them that those random network problems they are experiencing have a very high chance of being caused by it.

I'm currently tasked with fixing those problems (and implementing some new services which are not working as expected because of this issue), and I need a way to persuade them to just leave that f***ing service alone; sadly, personal experience seems to not be official enough.

I'm posting this as a BIG CAVEAT to everyone. I know it's not a standard Q&A, but I think this is something every Windows admin should know. There is a very real risk of falling into Big Troubles.

Microsoft has recently released Windows Management Framework 3.0 for Windows Server 2008 and Windows Server 2008 R2 systems, which includes some nice things native to Windows Server 2012 (like PowerShell 3.0) and lots of improvements to WMI, WinRM and other management technologies.

Windows Update is advertising it as an optional update.

Should I install it on my servers?

Update: As of 2012-12-19 Microsoft has removed the update from Windows Update after major compatibility issues with various products (including the ones being discussed here) have been reported by multiple users.

How to pause execution for a while in a Windows batch file between a command and the next one?

I'm proposing this to be a canonical question about enterprise-level Storage Area Networks.

What is a Storage Area Network (SAN), and how does it work?
How is it different from a Network Attached Storage (NAS)?
What are the use cases compared to direct-attached storage (DAS)?
In which way is it better or worse?
Why is it so expensive?
Should I (or my company) use one?

Suppose you have a fully virtualized VMware infrastructure: ESXi, vCenter, vMotion, HA, DRS, the whole package.

Inside, you have lots of VMs, which at any given time may reside on one host or another (that's the whole point of clustering, isn't it?).

You experience a power loss, and, one way or another, you manage to shut down gracefully all VMs and all hosts; let's not delve into this for now, let's just assume your UPS software can handle it. Or, at least, let's assume the shutdown was not so graceful, but everything is still able to come up again once power is restored.

Power comes back, and your hosts restart.

Your environment is quite complex, and it has natural dependencies between VMs: domain controllers should start first, an application server can't start unless its back-end DB server is already up and running, and so on.

We all know (or should hopefully know) how to configure automatic VM startup and how to specificy a VM startup order and delay on a single ESX/i host.

But how to do this across a whole datacenter?

Is there any way to tell vSphere "start these VMs in this global order, regardless of the physical host they are running on"?

Bonus points: if vCenter itself is running on a virtual machine, how does this change things?

Standalone ESXi (4.1) host without any vCenter Server.

How to backup virtual machines as quickly and storage-friendly as possible?

I know I can access the ESXi console and use the standard Unix cp command, but this has the downfall of copying the whole VMDK files, not only their actually used space; so, for a 30-GB VMDK of which only 1 GB is used, the backup would take 30 full GBs of space, and time accordingly.

And yes, I know about thin-provisioned virtual disks, but they tend to behave very badly when physically copied, and/or to blow up to their full provisioned size; also, they are not recommended for actual VM performance.

It is ok for me to shut down the VMs before backing them up (i.e. I don't need "live" backups); but I need a way to copy them around efficiently; and yes, a way to automate shutdown/startup when taking a backup would also help.

I only have ESXi; no Service Console, no vCenter Server... what's the best way to handle this task? Also, what about restores?

Are IP addresses with all zeroes in the first octet valid?

For example, can 0.1.2.0/24 be a valid subnet, with network address 0.1.2.0, broadcast address 0.1.2.255 and an usable address range from 0.1.2.1 to 0.1.2.254?

It looks like it should be valid, but it doesn't work, at least on Windows systems.

If it's not valid, then why?

A simple real-life question, inspired by a comment here:

Active Directory has supported inter-site replication using SMTP instead of direct RPC since its first introduction in Windows 2000.

But did anyone ever actually use it?

If yes, why was it choosen?
Was it easy or troublesome to set up and mantain?
Was it reliable?

Let's say I have a SQL Server database whose data files have been created with an initial size of 100 GB, but it only contains 10 GB of data. A database backup will then be only 10 GB in size.

I want to restore this backup to a different server (or a different database on the same server), but I don't want it to take the same disk space as the original one (100 GB), which is what happens by default.

I can't shrink the original database before taking a backup (it's a production database, and it needs that much pre-allocated space); I could shrink the restored database after the restore is done, but I would really prefer to have it not take up 100 GB while doing that; besides, in this specific scenario I don't have that much free disk space, so the restore isn't going anywhere.

Is there any way I can restore the database and have it only take up as much space as the actual data it contains?

This has been bugging me for a while.

We all know Active Directory is a LDAP database.

We also know that the Windows DNS service, when running on a domain controller, can store its data in AD instead of plain text zone files, thus taking advantage of AD automatic replication and removing the need for primary/secondary DNS servers.

The question: where and how are DNS data actually stored in Active Directory?

Can they be accessed using LDAP tools such as ADSIEdit?
Is any DNS entry an actual LDAP object?
An attribute in an object?
Something entirely different?

Since starting working where I am working now, I've been in an endless struggle with my boss and coworkers in regard to updating systems.

I of course totally agree that any update (be it firmware, O.S. or application) should not be applied carelessly as soon as it comes out, but I also firmly believe that there should be at least some reason if the vendor released it; and the most common reason is usually fixing some bug... which maybe you're not experiencing now, but you could be experiencing soon if you don't keep up with .

This is especially true for security fixes; as an examle, had anyone simply applied a patch that had already been available for months, the infamous SQL Slammer worm would have been harmless.

I'm all for testing and evaluating updates before deployng them; but I strongly disagree with the "if it's not broken then don't touch it" approach to systems management, and it genuinely hurts me when I find production Windows 2003 SP1 or ESX 3.5 Update 2 systems, and the only answer I can get is "it's working, we don't want to break it".

What do you think about this?
What is your policy?
And what is your company policy, if it doesn't match your own?

What about firmware updates (BIOS, storage, etc.)?
What about main O.S. updates (service packs)?
What about minor O.S. updates?
What about application updates?

My main interest is of course in updating servers, as client patch management is usually more straightforward and there are well known tools and best practices to handle it.

This is a followup to this question.

I've run some more tests; looks like it really doesn't matter if this is done at the physical console or via SSH, neither does this happen only with SCP; I also tested it with cat /dev/zero > /dev/null. The behaviour is exactly the same:

• Start a process in the background using & (or put it in background after it's started using CTRL-Z and bg); this is done without using nohup.
• Log off.
• Log on again.
• The process is still there, running happily, and is now a direct child of init.

I can confirm both SCP and CAT quits immediately if sent a SIGHUP; I tested this using kill -HUP.

So, it really looks like SIGHUP is not sent upon logoff, at least to background processes (can't test with a foreground one for obvious reasons).

This happened to me initially with the service console of VMware ESX 3.5 (which is based on RedHat), but I was able to replicate it exactly on CentOS 5.4.

The question is, again: shouldn't a SIGHUP be sent to processes, even if they're running in background, upon logging off? Why is this not happening?

Edit

I checked with strace, as per Kyle's answer.
As I was expecting, the process doesn't get any signal when logging off from the shell where it was launched. This happens both when using the server's console and via SSH.

Asking this after a prolonged discussion with a coworker, I'd really like a clarification here.

I launch a background process, either by appending "&" to the command line or by stopping it with CTRL-Z and resuming it in background with "bg". Then I log out.

What happens?

We were quite sure it should have been killed by a SIGHUP, but this didn't happen; upon logging in again, the process was happily running and pstree showed it was "adopted" by init.

Is this the expected behaviour?

But then, if it is, what's the nohup command's purpose? It just looks like the process isn't going to be killed anyway, with or without it...

Edit 1

Some more details:

• The command was launched from a SSH session, not from the physical console.
• The command was launched without nohup and/or &; it was then suspended with CTRL-Z and resumed in background with bg.
• The ssh session did not drop. There was an actual logout ("exit" command).
• The process was a scp file copy operation.
• Upon logging in again, pstree showed the process running and being child of init.

Edit 2

To state the question more clearly: will putting a process in background (using & or bg) make it ignore SIGHUP, just like the nohup command does?

Edit 3

I tried manually sending a SIGHUP to scp: it exited, so it definitely doesn't ignore the signal.

Then I tried again launching it, putting it in the background and logging off: it got "adopted" by init and kept running, and I found it there when logging back on.

I'm quite puzzled now. Looks like no SIGHUP was sent at all upong logging off.

In the life of a system administrator, always will come a moment when an IP subnet needs to be defined. Be it your small home LAN or the endless company WAN where madness lurks in the depths of unknown routes, IP addresses will always need to be choosen, divided and assigned to some device, deserving it or not. And, while in the "real world" of the public Internet you'll have to just obey your ISP's orders, you're free to choose your path and your ultimate destiny when it comes to your own private network.

As everyone knows (or should know), the mighty RFC 1918 states that private network IP addresses can only fall in three great blocks:

192.168.0.0/16
172.16.0.0/12
10.0.0.0/8

Which is your favorite one?
How big do you usually choose to make a subnet, regardless of course of how many devices you really need to connect to it?
Do you think it should be kept to a minimum, or should it be as great and glorious as possible?
Do you believe in the law and order of "round" subnets (/8,/16,/24), or do you prefer the anarchy and crawling chaos of "unround" ones?
Do you follow the Sacred School of Our Gateway Should Be .1, the Unholy Temple of No It Should Be .254, or the blasphemous teachings of the Order Of It Shall End With Whatever We Want It To End With?
Do you feel in your heart that Servers should have "low" addresses and Clients should use "high" ones? Or will only Fate define how the Server and the Client are to be called?
Do you always use (or try to use) the same ending numbers in all the subnets you manage, so that you may find your gateway and your DNS in the hour of your great need?
Do you believe in DHCP or in Static Addressing? And do you have faith in their hybrid child, DHCP With Reservations, even for not-client machines like network printers or, may all the Gods forgive you, Servers?

"Take this and divide it; this is my 2^32 address space,
 which shall be endlessly fragmented for all your addressing needs,
 until IPv6 may finally come."

This looks related to this one, but it's somewhat different.

There is this WAN link between two company sites, and we need to transfer a single very large file (Oracle dump, ~160 GB).

We've got full 100 Mbps bandwidth (tested), but looks like a single TCP connection just can't max it out due to how TCP works (ACKs, etc.). We tested the link with iperf, and results change dramatically when increasing the TCP Window Size: with base settings we get ~5 Mbps throughput, with a bigger WS we can get up to ~45 Mbps, but not any more than that. The network latency is around 10 ms.

Out of curiosity, we ran iperf using more than a single connections, and we found that, when running four of them, they would indeed achieve a speed of ~25 Mbps each, filling up all the available bandwidth; so the key looks to be in running multiple simultaneous transfers.

With FTP, things get worse: even with optimized TCP settings (high Window Size, max MTU, etc.) we can't get more than 20 Mbps on a single transfer. We tried FTPing some big files at the same time, and indeed things got a lot better than when transferring a single one; but then the culprit became disk I/O, because reading and writing four big files from the same disk bottlenecks very soon; also, we don't seem to be able to split that single large file into smaller ones and then merge it back, at least not in acceptable times (obviously we can't spend splicing/merging back the file a time comparable to that of transferring it).

The ideal solution here would be a multithreaded tool that could transfer various chunks of the file at the same time; sort of like peer-to-peer programs like eMule or BitTorrent already do, but from a single source to a single destination. Ideally, the tool would allow us to choose how many parallel connections to use, and of course optimize disk I/O to not jump (too) madly between various sections of the file.

Does anyone know of such a tool?

Or, can anyone suggest a better solution and/or something we already didn't try?

P.S. We already thought of backing that up to tape/disk and physically sending it to destination; that would be our extreme measure if WAN just doesn't cut it, but, as A.S. Tanenbaum said, "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."

Windows Server 2008 introduced read-only domain controllers, which receive a full replica of the domain database but can't modify it, just like a good old Windows NT BDC.

I know all the technical ins and outs of how to run those semi-DCs (I just passed 70-646 and 70-647), but still I don't have a clear answer to the most important question of all: why should you use them?

This comment from TheCleaner really sums it up for me:

@Massimo - yes, you are correct. U are looking for a compelling reason for an RODC and there isn't one. It has a few additional security features to help alleviate branch office security and really only needs to be deployed there if you don't have a DC there already and are anal about its security.

That was the same I was thinking... a little increase in security, yes, sure, but definitely not so much to be worth the hassle.

You sure witnessed it with your own eyes (or are going to) sooner or later: that dreadful project/system/situation where something got SO screwed up you just can't believe it actually went like it did.

Mismanagement? Misbudgeting? Misunderstanding? Just silly, plain ignorance? Name your cause, it sure happened (and keeps happening a lot, sadly; see here).

Describe it here, for amusement (although somewhat of the cynic kind) and learning (hopefully).

Some rules:

• This is not the place for random (even if utterly devastating) admin errors, so please avoid "argh I mistyped that rm -r" or "OMG I JUST COPIED THE CORRUPTED DATABASE OVER MY LAST GOOD BACKUP" (been there, done that); those things are better here. This is about "what sort of drugs was exactly under the influence of who designed/implemented this system?".
• One WTF per post, so they can get properly commented.
• Please post something you actually witnessed :-)
• If it was you who did it, it still qualifies :-)

I'll be adding some material soon, feel free to add your own; and please do :-)

Can VMWare ESX or ESXi be installed and used inside a virtual machine?

It can be installed inside VMWare Workstation or Server, but then it doesn't work; the main symptoms are:

• It runs REALLY slowly.
• It lets you create VMs, but when powering up them it gives an error stating "You may not power on a virtual machine in a virtual machine".