I'm having exactly this problem as well.
Wired and wireless, no matter which wireless network I use (I have two with two different routers).
The issue seemed to start spontaneously, with the Mac Mini Server refusing to take DHCP from anywhere and just self-assigning an IP every time I try.
Cleared all Airport and network related plist files, and nothing I tried has worked so far.
Of course the work around is to manually assign the server an IP (and as an option set-up IP reservation at the router) and that works (probably not a bad idea for a server).
The only change I made was to turn off Security in server preferences and I am now back to the mini-server accepting and an IP from the DHCP server on the router. That said I don't believe that was the issue in the first instance.
Best regards. Terry
Ok. I solved this problem on my machine and it sounds like you all may be having the same issue. I'm posting my resolution here in hopes it can save some other Mac users a bit of frustration.
In my case, my Mac Mini server had a messed up firewall plist, resulting in the machine not even responding to DHCP, so I:
1) Turned off the firewall
2) Deleted the configuration file at /Library/Preferences/com.apple.alf.plist
3) Turned firewall back on and recreated the rules I had previous to it going rogue on me.
This process is also described here: http://www.lockergnome.com/it/2009/02/09/mac-dhcp-wireless-connection-broken-wit h-self-assigned-ip-address/
All the credit to Mr. Hughes for this one, because I didn't even think the firewall could freak out to that extent, but there you go. :P
Hope this helps someone else!
You guys are wrong! It is totally NORMAL and is totally what Server Mac mini does in its position.
Mac mini OS Server considered itself as a SERVER, NOT client, thus, you cannot treat it as a client. Normally, Mac mini will get its IP address easily from a DHCP Server, it could be from a Router or a PC Server or a Mac Server or directly from ISP's Server(probably with 1 arranged IP).
When you are using Mac OS Server in Mac mini, you won't get an IP easily from a DHCP Server, whether it is from a Router or another Mac Server or PC Server or ISP.
In fact, a DHCP is still sending some info exchanged with your Mac mini Server, so you can still hook on the Internet but a exclamation mark will appear on AirPort.
I had the same problem - I returned home a few days after setting up the server and it was no longer connected to the Internet, and could not get an IP address through DHCP, neither from Ethernet nor Airport.
Thanks to this discussion, I realized it has to be a Firewall problem:
It seems that the FW blocks the DHCP request/reply traffic with the router. The server dropped the IP connection apparently because the DHCP lease needed to be renewed while I was away. As soon as I was able to turn the FW off, DHCP could be renewed. When I turned the FW on again, the renewal appeared to take place (the address information on the settings pane was correct) but within about ten seconds the Ethernet connection had died (and the address information on the pane was cleared).
The quirk in the process was that after restarts etc. I was not able to turn the FW off, because the server admin pane did not work, apparently as it did not get a connection to the LDAP server as it had no working IP address etc. So to get that working, I had to first get the IP addresses working, and I was able to do that by setting them manually.
So there seems to be nothing wrong or weird with the FW settings, it is just easy to configure the system so that this problem emerges by accident: you choose to set the IP dynamically with DHCP when the FW is off and then you turn it on and everything continues to work until the time comes to renew the IP.
So, to solve the problem there are two routes:
1) if you want to assign the IP dynamically from DHCP, you need to either not have the FW running or open up the ports necessary for the traffic. I did not research this option but browsing a bit it appears to involve ports 68 and 69.
2) set the IP manually, so that the server does not need to route DHCP traffic through its FW. To have a static local IP address of course makes sense for a server anyway in most cases.
Thanks for the previous posts that pointed in the right direction.
Mauricette has a point.
A server function is not designed to accept a floating or dynamic IP address. If that is the case, how do you create firewall rules that prevent those unnnecessary ports being left opened from being attacked by rogue machines in Romania and China on a hourly basis when you announce to the world that your server is available if the server IP address keep changing due to the DHCP lease change? Yes, they do have bots that do this VERY EFFICIENTLY!
By changing the very nature of your firewall rules by working with DHCP, you are opening ports you do not know to accommodate DHCP dynamic addressing, which was the reason why your Mac Mini Server stopped working in the first place. It's ok for a client, since a client isn't serving any files to any one right.
By using client based firewall rules, you are exposing your server to attacks and when they get through your Mini server, which they can if they are persistent, they get into your home network and then whatever file server services you have opened and unprotected at the time WILL BE copied by these people easily.
I have a client once who did just that. She was attacked, the hacker went through her network like a rampaging bull. They were from China. My Synology RAID server gets this attack all the time, but I have a well establish IDS system and the Synology RAID has logs that tracks attacks.
For a server setup. Use static IP and then build a strong firewall around it and protect it and never compromise.
Recently, I just noticed someone somehow hacked and broke my WPA-PSK AES passkey for one of my Wireless N network router. It was not set up with a strong password though, but thankgod I had a firewall around that so my internal networks were safe. So this teaches you that if someone wants in bad, they will get in.
Hope this helps.
This is not a firewall problem and our Mac Mini Server certainly is not running its own DHCP service. (Anyone can check that easily enough, btw, by looking for ports 67 and 68 in the output of sudo netstat -an | grep udp)
Watching the wire from another machine you can also see the DHCPDISCOVER, DHCPOFFER, DHCPREQUEST and DHCPACK packets going back and forth.
In our case we're running a Windows 2008 R2 DHCP server with a MAC reservation for the Mac Mini Server's ethernet MAC (its WiFi is turned off). What I found is that is you specify a DHCP Client ID in the settings it would kybosh the reservation in Windows and send back a dynamic address instead. Don't set the DHCP Client ID and it works OK.
In the DHCPDISCOVER packet it is prefixing the Client ID with a NUL character, so I'm wondering if this is a actually a bug...
udp/67 2012-05-18 13:04:41
op = BOOTREQUEST
htype = HTYPE_ETHER
hlen = 6
hops = 0
xid = 659fb5a7
secs = 1
flags = 0
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 406c8f03e555
DHO_DHCP_MESSAGE_TYPE(53) = DHCPDISCOVER
DHO_DHCP_PARAMETER_REQUEST_LIST(55) = 1 3 6 15 119 95 252 44 46
DHO_DHCP_MAX_MESSAGE_SIZE(57) = 1500
DHO_DHCP_CLIENT_IDENTIFIER(61) = \x00cripps
DHO_DHCP_LEASE_TIME(51) = 7776000
DHO_HOST_NAME(12) = cripps
padding  = 000000000000000000000000000000000000