Your experience of Server app in an AD environment is pretty much standard in my experience. I've been involved in many mac AD integrations over the years at many different locations and I've seen similar behaviour time and time again. It also happened when WorkGroup Manager (the forerunner to Profile Manager) was used. I think its a 'feature' of the app and not likely to be changed any time soon. However I have some hope that Apple's next offering may, finally, change this behaviour and become the management tool many of us have wanted?
As far as I know there is no 'cure'. However there are a few things you should be aware of that may help? First question is what tld does your AD domain use? If its .local then you're on a loser already. As it happens, Server App/Profile Manager reliability in reading AD groups tends to be worse when internal DNS Services are based around .local. This is the main reason why I've seen this behaviour time and time again over the years. Other reasons (again DNS based) could be related to IPv6. If your AD domain is not using IPv6 then disable it on all your macs, especially the mac server. How do you disable it? Launch terminal and issue this command:
sudo networksetup -setV6off Ethernet
sudo networksetup -setV6off Wi-Fi
The above is for wired and wireless network connections. If it was me I would not use macs over Wi-Fi for anything meaningful in an AD environment. Too flakey. If you're not using Wi-Fi then don't run the second command. Finally heavily proxied networks can also cause problems. If you can add the mac server to a proxy whitelist then do so as it can alleviate the problem, sometimes. OS X (and especially Profile Manager) does play well generally behind a proxy.
Not seeing the Groups is not really a show stopper and provided you can 'see' groups in the way you already do and you can list them in dscl (a command line utility) or Directory Utility then you should be OK? However its not great if you're trying to apply policies at group level. What I normally do is manage the devices directly instead or create a Group (this would be an OD group) within the Server App, search for desired AD groups and when they appear add them to the OD group. Basically you're nesting AD groups within a single OD group. First time a user within the AD group logs in, they'll pull the relevant policy you've assigned to the OD group and this will be cached locally on the mac workstation they log into. This will stay with that workstation so the next time they log in they'll get the same policies irrespective of whether the Server App can 'see' AD groups or not. In my experience this tends to work when users move from mac workstation to mac workstation.
None of the above may be applicable to your situation and none of it may be useful, but its something you can easily try and in my experience it helps. You've nothing to lose at any rate.
