My mobile device of choice at work is a 13″ MacBook Air. It’s a great system that is extremely lightweight (see: portable). Unfortunately, I need the ability to console into switches to make configuration changes and this computer does not have a serial port. Thankfully, I have a USB to Serial Adapter that I keep in my “go bag.” It doesn’t work out-of-the-box in OS X 10.8 Mountain Lion, but it isn’t too difficult to configure.
I followed a few articles I found online (primarily, this one: http://plugable.com/2011/07/12/installing-a-usb-serial-adapter-on-mac-os-x).
- Plug in the USB to Serial Adapter.
- Click Apple menu > About This Mac > More Info … > System Report …
- Click on Hardware > USB > verify you see USB-Serial Controller D on the right.
- Download the driver here: http://plugable.com/drivers/prolific (I downloaded the PL2303 MacOSX10.6 dmg v1.4.0.zip file).
- Install the driver, then reboot the computer.
- Click on System Preferences > Network > “+” > Interface. If it was installed properly, you will see something like “USB-Serial Controller D.”
- Click cancel.
Now that the device and driver are installed properly, you can download a terminal emulator like ZTerm to make a connection to the serial device.
Recently, I was in the process of installing a new Windows Server 2008 R2 domain controller into a Server 2003 Native domain with a single Server 2003 domain controller.
During the process, I ran all of the necessary checks (ie: dcdiag, etc.) to verify everything in the domain looked correct. I received an issue when running `netdom query fsmo` that basically said it could not complete the operation. I used the GUI to verify all of the FSMO roles and found that there was an error listed in the schema master section.
Having never come across this before, I did research and found this Microsoft KB (255504) that explained how to seize a FSMO role if one is “lost.”
WARNING: Make sure you are absolutely certain that the FSMO role is lost and the system that used to hold this role is not just having issues or is powered off. If at all possible, it would be better to “fix” the issue, rather than just overwrite the settings with a new FSMO role holder.
Here is the text from the KB that I followed and that successfully let me take over the lost schema role (I performed these steps on the Windows Server 2003 domain controller before promoting the Windows Server 2008 R2 system):
Seize FSMO roles
To seize the FSMO roles by using the Ntdsutil utility, follow these steps:
- Log on to a Windows 2000 Server-based or Windows Server 2003-based member computer or domain controller that is located in the forest where FSMO roles are being seized. We recommend that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user should be a member of the Enterprise Administrators group to transfer schema or domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the Infrastructure master roles are being transferred.
- Click Start, click Run, type ntdsutil in the Open box, and then click OK.
- Type roles, and then press ENTER.
- Type connections, and then press ENTER.
- Type connect to server servername, and then press ENTER, where servername is the name of the domain controller that you want to assign the FSMO role to.
- At the server connections prompt, type q, and then press ENTER.
- Type seize role, where role is the role that you want to seize. For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press ENTER, or see the list of roles at the start of this article. For example, to seize the RID master role, type seize rid master. The one exception is for the PDC emulator role, whose syntax is seize pdc, notseize pdc emulator.
- At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.
I recently wanted to look at what Group Policy options existed for managing a piece of software, so I downloaded the relevant ADMX files from Microsoft and couldn’t remember what to do with them.
After some quick searching, I found a blog post that answered my question – http://tigermatt.wordpress.com/2009/06/06/where-do-i-put-my-admx-files/
- Copy the ADMX files to %systemroot%\PolicyDefinitions (%systemroot% should be C:\WINDOWS).
- Copy the ADML files (if they exist) to %systemroot%\PolicyDefinitions\en-US (again, %systemroot% should be C:\WINDOWS).
- Restart your Group Policy Management Console for the policy files to appear, no need to add a new template.
Also, a good piece of information that was noted on this blog post was that the ADMX/ADML files don’t need to be present on every machine on the network, just on the machine where you are creating/editing the policies.