Firefox

We publish our applications via UAG, and use a Freyer device to authenticate fobs that have been distributed to users. These fobs are linked to their accounts in AD. They are also then required to input their AD credentials. Without both part of the login access is not granted

We use "dual factor" or 2 factor authentication. This normal comprises of a remote access fob linked together with the users domain credentials. Like yourself though I wasn't aware of this being any law....surely if a company had no care about their data they could have no authentication? EDIT: sorry you mean law, relating to the SIM application...sorry have never used this, but assuming it holds school data - possibly

Oh the joys of Microsoft Licensing. Hopefully this helps shed some light on the subject Licensing Windows Server in a Virtual Environment - virtualboy blog - Site Home - TechNet Blogs The biggest change for the Datacenter Edition is that it's licensed per processsor and not per physical server

If you only have 1 DC in your environment, then sure a restore from backup is the way to go. However if you have multiple DC's and to the best of your knowledge replication is working. Then I would never try a restore, and always go for a rebuild and repromo. This is unless your backup happened to be minutes before the failure - otherwise you'll have no end of users moaning that their passwords are no longer working, the people who manage your accounts wondering where their days work has gone.

I would also make sure to follow best practice, when seizing the role, make sure the server is rebuilt with a different IP\name. In most cases this shouldn't be necessary but it's advised to have a "clean" install. In some cases you can have a server failure and still be able to move the roles over cleanly. In this case I'd happily keep the same name/ip if the server is rebuilt

Do you have control over this external server? If so you will have to consider putting a trust in place (through Active Directory Domains and Trusts) Depending on what the application is and how it works, I would consider a 1 way trust, so that your external server trusts your DC, but not the otherway round. I would also make this trust non transitive

Computer Configuration>>>>Policies>>>>Windows Settings>>>>>Administrative Templates>>>>>System/Logon Assign a default domain for logon Apologies if I mis-understood your problem.

Move the machine out into a workgroup first then back into the other domain. This will clear most of the GPO setting from the old domain. However, GPP mode actually targets individual settings and reg keys, in old terms this would be known as "Tattooing the registry". In affect you have a setting to change a registry key, simply no longer applying that setting won't change the reg key back. To revert this change you either need to find the reg key affected and manaulyl change it back, or change the GPP setting to update the key to your new desired state.

To accomplish this we actually set the user part settings for the Sessions host in the domain of the Session Host. We went very granular in having a seperate policy of user part and computer part. Apply both policies to the Same OU. In the user party policy configure 1 computer part setting which turns loopback processing on (either merge or replace) Then configure the users settings you want in this policy. I can think of no technical reason why you'd need 2 policies, so feel free to just have 1 policy that configures the computer and user parts (just make sure loopback is configured). Then for the scope of the policy we have a universal group, which contains a global group from the user domain, containing the users the settings should apply to when logging onto that particular Session Host. This means we can have different user part settings for every Session Host if we so wish. Hope that makes sense - was a nightmare to setup, but fairly quick process for us to follow to create a new Session Host now. - Just to note splitting the Session Hosts into another domain would not be my preferred approach, it was one of those "make this work" scenarios

Nice simple reg key fix in the end [HKEY_CURRENT_USER\Software\Policies\Microsoft\MMC\{F7E7A18B-F9AA-45C7-A234-CE2082268844}] "Restrict_Run"=dword:00000000

Well I logged an advisory call with Microsoft, and have been told this is not currently possible with a default GPO setting - They believe there is a registry setting that can be set via Group Policy Preference to enabled this. Currently waiting to be sent this info, but will update here when I've had chance to test to see if this works as expected.

Thought you were onto something then, unfortunately it seems even when running from a Windows 7 machine with the client install, group policy doesn't show me thios option

Hello, We currently have a group policy for MMC snap-ins which is set to "Restrict users to the explicitly permitted list of snap-ins" From here we obviously list all the snap-ins they are allowed to access. We now have a request to allow access to a new App-V snap-in. The issue I have is this snap-in obviously isn't in the list to allow. By default if it has not been allowed it will be denied, so anyone trying to access the App-V snap-in gets the "This has been restricted by policy". The only way I can see around this, is to change the option "Restrict users to the explicitly permitted list of snap-ins" to disabled so all snap-ins are available, then put a deny on all those I don't wish to open up. As App-v is not on the list, it will now be allowed by default. My issue is, I am now open for any future snap-ins to be run and will have no way to restrict them. Anyone else got a similar setup.

assuming your device has the netdom command installed, this should work I think netdom reset ComputerName /domain:FQDN /server: NameofDCinDomain /UserO:Useraccount with rights to reset object /PasswordO:PasswordofAccount

There error is pretty harmless, it's caused by running in a mixed mode setup and should disappear when you go fully 2008. I can't find the article right now, but there was a change in the way 2008 handled the kerberos tickets

You are happily forgiven for thinking that - the argument is then they don't want logs all the time, only when issues are experienced. If I could just get SCOM installed it would relieve a lot of the headache - but the powers that be deemed this won't happen. For the HP monitoring, I can understand it needs a service account to report back to the management server, I'd just really like to not make this a DA.... Your "Rule of thumb" is exactly how I believe any setup should be, unfortunately people seem to think they're missing out on something by not being a DA.......just last week I had to add 4 new people, for no other reason then they told their manager they wanted it!....then despite my misgivings I was told to make it happen. I have now resigned myself to the fact that our DC's will be accessible by any number of people - so I have changed tact to see if I can try and delegate some access and hopefully talk management into reversing some of their decisions.

I know by it's very nature a DC does not have a local admin as such. However I am starting to get an increasing number of requests for DC administration. The way our teams here are broken up, mean that we have a seperate Performance team, that would need to be able to run certain tasks on a DC, such as perfmon, eventvwr, read only to services. (This was seem easy to manage, but delegation to the MMC doesn't seem to work) Another team look after the hardware and require the HP insight Manager to have admin rights to be able to install an agent and report on HW failures. I'm really trying not to add more accounts to the Domain Admins group then really necessary, but it seems delegation on a DC doesn't really exist. This is running Windows 2008 R2.....the old 2003 DC's seemed to be less secure, and we had ways round this. Any thoughts? or am I resigned to having more DA's?

Sorry to burst your bubble, but we run scripts from within windows that configure our BIOS settings. These include Enabling WOL, Turning TPM on

I assume the working machines use the same DNS server as the one not working? If this is the case, try running ipconfig /flushdns from the broken machine, then ipconfig /registerdns Failing that, manually check DNS has the correct records, then from in DNS right click the server name and "Clear Cache" Do a flushdns from the DNS server then run the same commands again from the broken machine

np...sounds like you have it worked out. To save you adding your machines manually once you get KMS up and running, these LDAP queries should do the trick LDAP://FQDNofDomain??sub?(&(objectClass=computer)(operatingSystem=Windows 7*)) LDAP://FQDNofDomain??sub?(&(objectClass=computer)(operatingSystem=Windows Server 2008*)) (Note: no space between "Win dows" not sure why it did that

The count for KMS needs to be >5 for servers, but this is a combination of 2008 and Windows 7. So you can add 2 Windows 7 devices to your setup and KMS for servers should then activate. (Note: for Windows 7 to activate the count needs to be >25) Alternatively fire up 2 virtual 2008 servers to push you over the count limit, until you have enough devices on the domain to be able to remove these.

Incase anyone comes across the same issue...this was caused by my http line missing a variable. instead of http://certserv/CertEnroll/server1.crl it should read http://certserv/CertEnroll/server1.crl we then ran the certutil -crl command and the location changed to "OK"

If you install a DC on Hyper V...one gotcha to look out for is Time Sync. Make sure you unselect the option telling the guest to get it's time from the host. This can cause all manner of issues.

Having a small issue here. Installed an offline root CA...and then configured an Enterprise sub CA. Everything seems to look ok with the exception of one of the locations. DeltaCRL Location #2 - Unable to Download - http://certserv/CertEnroll/server1.crl However when I manually run this link within IE it loads fine. This is also the location for CDP Location #2 and the status for this is "OK" Is there something obvious being missed?

If you're going to use RA...then I would strongly advise you get the latest Microsoft Critical patches rolled out to every device. Microsoft warns of RDP attack within next 30 days ? The Register