Repairing a charred/burned/broken cable on an Apple Magsafe charger


I have spoken in a previous blog post about some issues with Apple hardware design here. To briefly recap, it is of my beleif that in general, Apple hardware is  very well designed. However, they often overlook functionality in favour of form, sacrificing important aspects such as durability so that “it looks nice”. A good example of this is the Magsafe adapter. In a bid to improve aesthetics, Apple shortened the rubber strain-relief grommet that protects the power cable from fraying at the charger end, and the connector end to the laptop. The metal strands inside the cable gradually begin breaking from normal use until eventually, with only a few strands left carrying a large amount of current, the last few strands overheat resulting in a burning smell and the the connection breaking completely. After Apple received many complaints with regard to this problem with the original Magsafe adapter, they extended the length of the rubber on the grommet to improve the durability of the cable. However, in me experience, this wasnt enough: the cable still ends up fraying, and the hardening of the rubber in the grommet over time only aggravates the issue. They also introduces a replacement program, details of which you can find here. However, this does not cover anywhere outside of the United States.

In case you find yourself in a similar situation as I was, here is a short guide on how to repair the cable on your magsafe adapter, without having to fork out the $80 for a new one. 
First off, you will need a large pliers, a high wattage soldering iron (I used a weller 75watt), solder, some cable ties of various sizes, a drill and a small drill bit, some glue and a sharp knife. 
1. Remove the plug from the Magsafe adapter. 
Removing the plug from a Magsafe adapter

2. Apple have ultrasonically welded the two plastic shells that cover the adapter. They do this by vibrating the two halves against other at such a high rate to melt the plastic at the junction and thus sticking them together. This results in the Magsafe adapter being pretty difficult to open without making some messy cuts in opening it up. So here is a quick tip on opening them up: Flip open the cable tidy arms and insert the pliers into the gap. Then slowly and firmly open the pliers pushing the two parts of the case apart in the process.

Insert a pliers in the gap for the cable tidy 
Open the pliers, splitting the case open 

Viola! An opened magsafe adapter with very little tool marking or scratching to the plastic.

Opened Magsafe adapter
3. Now, bend some of the plastic and copper shielding back around where the cable meets the circuit board to reveal two large solder points. Make a note of where the black cable and the white cable are soldered into the board. To help you, the board should be marked “GND” near the black cable. 
Solder points for Magsafe cable. White is positive, black (GND, cable shield) is negative
4. Using a high power soldering iron, desolder the two points and gently pull the cable from the board. You may find it easier to solder the points by removing the shielding from the circuit board. I left it on here. 
Weller 75w iron
Cable successfully desoldered from Magsafe adapter
5. Taking the cable, use a sharp knife to make a cut after the break in the cable. 
Cutting the good cable from the damaged cable
The damaged part ad grommet removed from the cable
6. Now, using the pliers again, pull the old black wire, and the white wire out of the grommet.  You will be left with a hole in the grommet as shown below. 
Removing the wires from the damaged part of the cable
The grommet, with the outside insulation of the cable left
7. Now, drill a hole all the way through the grommet removing the old cable and some of the grommets plastic along the way. You should make the hole large enough to pass the cable through, as shown below. 
Drilling the outside insulation of the damaged cable from the grommet
Weaving the good cable through the now cleared hole in the grommet

8. After you have passed the cable through the grommet, it is time to prepare the cable for soldering back to the board. Using the sharp knife, remove about 20mm of rubber insulation from the cable. Further remove about 3mm of insulation from the inner white wire. Then tin the ends of both cores using the soldering iron as shown below. 

Removing some outside insulation from the good cable
“Tinning” i.e. applying solder to the exposed positive and negative cable.
 A good tip here is to twist the ends before soldering. 
9. Now, carefully solder both wires back to their respective points on the Magsafe circuit board. 
The ends of the cable correctly soldered into place
on the circuit board. 
10. Place the circuit board back into one of the plastic shells of the cover. If you have done everything correctly so far, the adapter should be able to charge your laptop as this stage. If you are comfortable testing the adapter while the cover is off, do so now. Or else continue with the guide. 
Placing the circuit board back into one of the covers
11. Using a small cable tie, wrap it around the cable as tight as you can just inside the plastic cover. This is done so that the cable cannot be accidentally pulled out of the adapter during use. 
Adding a cable tie to the good cable

12. Run the plastic grommet down the cable back into position in the plastic shell.

Placing the grommet back into the shell
13. Using some glue, make a small bead all around the perimeter of the shell. Use the glue sparingly, but cover all the edges where both halves meet. 
Adding glue to the edge of the shell
14. Press the second half of the plastic shell back onto the Magsafe adapter. Wriggle the two halves to get them into place properly, and then firmly press the two halves back together. 
Squeese the two halves together to make sure that the glue spreads. 

15. Using some large cable ties, wrap them around the Magsafe adapter and tighten them using a pliers. You will need the two halves to be very tight together as the glue dries, or else the two cable tidy arms can fall out.

Adding cable ties around the adapter to make sure that they glue together properly.
16. When the glue has dried, remove the cable ties. You should be left with a working adapter that hardly looks like it was opened at all!
The finished, now working, adapter. 

Unfortunately I accidently ripped some of the rubber off the grommet as I was drilling through it, so go easy on that drilling! I have also repaired a few adapters where the cable has broken and burnt on the connector end. This is a slightly more difficult repair, but I can make a guide if requested.  



Sharing a printer on Windows 2008 R2

So, how hard can it be to share a printer?

Well, as it turns out, harder than you think, or than it should be!

While trying to share a printer on one of our fileservers we ran into various nice error messages.

So here’s what happened and how I fixed it:

On one of our sites, a printer broke down, and got replaced. The replacement printer was exactly the same make and model. A colleague of mine configured the printer with an IP address, and tried adding it to the server, but no matter how he tried, he always ran into the following error:

Printer Settings could not be saved. Operation could not be completed (Error 0×00000001)

A bit of googling pointed towards the windows firewall. Surely that can’t be the case, we have it disabled via GPO!

Let’s test. I turned off the firewall service completely, and the error message changed:

Printer Settings could not be saved. Operation could not be completed (Error 0x000006D9)

Well, that’s a known issue at least:

So, you can’t share a printer when the firewall service is not running? sounds really weird to me, but ok.

Starting the firewall service again gives me the previous 0×00000001 error again. Ok, let’s see what happens if we enable the firewall.

I used regedit to temporarly remove the GPO settings, checked the firewall that I would still be able to access the server via RDP if I enabled it, and enabled the firewall.

Tried sharing the printer again, same 0×00000001 error still! :(

Then I rememberd looking at the firewall rules. Looks like all of them were deleted at some point, and replaced by 1 simple Allow Any Any rule. Surely that should work, right?

Wait… The KB article which I just linked above stated this “If sharing is being performed for the first time, the following incoming rules are enabled during this process”

Enabled… surely they would be created if they do not exist, right?

Well, let’s test. By default there are a couple of rules for file and print sharing in the Windows firewall:

File and Printer Sharing (Spooler Service – RPC-EPMAP)
File and Printer Sharing (Spooler Service – RPC)
File and Printer Sharing (Echo Request – ICMPv4-In)
File and Printer Sharing (Echo Request – ICMPv6-In)
File and Printer Sharing (LLMNR-UDP-In)
File and Printer Sharing (NB-Datagram-In)
File and Printer Sharing (NB-Name-In)
File and Printer Sharing (NB-Session-In)
File and Printer Sharing (SMB-In)

For our setup they were removed, since the Allow Any Any should allow it anyways! Let’s add these again, and there’s even an easy way to do this:

netsh firewall set service type = fileandprint mode = enable


After adding these rules again, sharing a printer works again. Even if the firewall is disabled, these rules MUST exist to be able to share a printer, go figure!

Troubleshooting NTDS Replication 1864 Error

One of our DC’s reported the following error in the eventlog:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 3/20/2012 4:12:27 AM
Event ID: 1864
Task Category: Replication
Level: Error
Keywords: Classic
Computer: <FQDN DC NAME>
This is the replication status for the following directory partition on this directory server.

Directory partition:

This directory server has not recently received replication information from a number of directory servers. The count of directory servers is shown, divided into the following intervals.

More than 24 hours:
More than a week:
More than one month:
More than two months:
More than a tombstone lifetime:
Tombstone lifetime (days):

Directory servers that do not replicate in a timely manner may encounter errors. They may miss password changes and be unable to authenticate. A DC that has not replicated in a tombstone lifetime may have missed the deletion of some objects, and may be automatically blocked from future replication until it is reconciled.

To identify the directory servers by name, use the dcdiag.exe tool.
You can also use the support tool repadmin.exe to display the replication latencies of the directory servers. The command is “repadmin /showvector /latency <partition-dn>”.

Ok, so we try repadmin, as stated, from a cmd run as administrator:

<i>repadmin /showvector /latency DC=ForestDnsZones,DC=azchem,DC=com </i>

Caching GUIDs.
130ed804-3da1-4a86-8c33-b00fd90002ff @ USN 658186 @ Time 2007-09-28 12:55:08
0aecc5ad-9da6-4ab3-9128-a417c7809cd7 @ USN 2732181 @ Time 2007-10-01 14:27:59
01a799fc-5706-4c52-8ee4-314b249ec7f9 @ USN 73790 @ Time 2008-08-15 10:43:20
7a9e2324-c4b1-46a4-a8a7-db01b0bb496f @ USN 3682535 @ Time 2009-11-13 01:55:28
bce2c1f9-5bbf-436d-90fc-1a6c826964ea @ USN 5708078 @ Time 2010-03-26 10:54:40
3c2e92ea-2a98-4a81-9db8-c4efe3360e20 @ USN 23414395 @ Time 2010-07-07 20:34:02
5a3d9351-45b0-44ea-bb86-070d27bccb17 @ USN 2876006 @ Time 2010-08-24 04:33:23
2b006516-30c6-4738-b633-d82eeffd9c24 @ USN 5498207 @ Time 2011-05-17 09:13:49
812f6dd7-1303-4a9c-9e2e-df32236673d6 @ USN 4102348 @ Time 2011-06-09 15:48:33
15595706-d844-4a42-97a3-0655db8e9785 @ USN 4292841 @ Time 2011-06-30 10:41:22
c2ab703e-28da-4541-b6cd-f6948b478753 @ USN 32442104 @ Time 2011-07-07 11:41:42
6574d771-15a7-49e8-82e2-fe0f23a3db5f @ USN 3233536 @ Time 2011-07-25 09:12:12
811bdfc1-df5c-4697-9ec5-2f8098544b7b @ USN 32218002 @ Time 2011-08-10 13:04:25
b3829fa5-9eae-4253-a262-f6125bbe3d6d @ USN 18683486 @ Time 2011-09-01 14:51:36
5572cb4e-e996-448f-af32-89475286d15b @ USN 13527227 @ Time 2011-09-02 09:54:06
Savannah-SAV\DSAVDC01 @ USN 10289804 @ Time 2012-03-23 04:50:05
Valdosta-VAL\DVALDC01 @ USN 1390968 @ Time 2012-03-23 04:50:05
Dover-DOV\DDOVDC01 @ USN 1660531 @ Time 2012-03-23 04:50:05
FreudenbergIT-FIT\DFITDC02 @ USN 2491220 @ Time 2012-03-23 04:51:07
Sandarne-SAN\DSANDC01 @ USN 6033044 @ Time 2012-03-23 04:52:51
Niort-NIO\DNIODC01 @ USN 1405488 @ Time 2012-03-23 04:52:51
Oulu-OUL\DOULDC01 @ USN 1892939 @ Time 2012-03-23 04:52:51
Chester-le-Street-CLS\DCLSDC01 @ USN 1527732 @ Time 2012-03-23 04:57:48
Gersthofen-GER\DGERDC01 @ USN 1076336 @ Time 2012-03-23 04:57:48
Almere-ALM\DALMDC01 @ USN 7940275 @ Time 2012-03-23 04:58:12
Almere-ALM\DALMDC03 @ USN 17002878 @ Time 2012-03-23 04:58:27
Marianna-MAR\DMARDC01 @ USN 1145283 @ Time 2012-03-23 04:59:19
Pensacola-PEN\DPENDC01 @ USN 1231738 @ Time 2012-03-23 04:59:19
Panama-City-PAC\DPACDC01 @ USN 3644190 @ Time 2012-03-23 04:59:19
FreudenbergIT-FIT\DFITDC01 @ USN 2521162 @ Time 2012-03-23 04:59:19
Almere-ALM\DALMDC02 @ USN 9758370 @ Time 2012-03-23 05:05:03
Jacksonville-JAX\DJAXDC01 @ USN 8045224 @ Time 2012-03-23 05:05:44
Jacksonville-JAX\DJAXDC02 @ USN 8371544 @ Time 2012-03-23 05:05:44
Jacksonville-JAX\DJAXDC03 @ USN 17095540 @ Time 2012-03-23 05:19:36

Note: I don’t bother removing sitenames or DC names. a quick google will show you where I work at the moment, and all sites are on the corporate website anways. And I don’t believe in <a href=””>Security through obscurity</a> anyways.

So, we’ve got a replication problem. 1 DC has not repliacted for the past 7 days

All the GUID’s you see are from deleted DC’s, so that’s normal.
What I also notice is that 1 DC is missing, the one in China. This also is normal, since it is a RODC, and that won’t show up as described <a href=”″>here</a>

Cluster validation error: This resource does not have all the nodes of the cluster listed as ‘Possible Owners’

While trying to validate a cluster here, I got this message:

“This resource does not have all the nodes of the cluster listed as ‘Possible Owners’. The group that this resource is a member of will not be able to come online on any node that is not listed as a ‘Possible Owner’.”

If I try to move it to another node, and that node is not in the list of possible owners, you get a nice message

“Operation has failed.
The action ‘Move to node <nodename>’ did not complete.

Error code: 0×80071398. The operation failed because either the specified cluster node is not the owner of the group, or the node is not a possible owner of the group.”
The problem in this is that once a shared volume becomes a CSV, you cannot modify the possible owner list from the Failover Cluster Manager Console anymore.

The only way to fix this it to do it from the command line, with the cluster command.

you can do a “<i>cluster resource “<cluster disk name>” /listowners</i>” to get a list of possible owners.

Listing possible owners for resource ‘Cluster Disk 5′:
Possible Owner Nodes

In this case the second cluster node is missing. Easily fixed:
<i>cluster resource “Cluster Disk 5″ /addowner:ClusNode2</i>

Adding ‘ClusNode2′ to possible owners of ‘Cluster Disk 5′…

after which a check will give the full list of nodes:

<i>cluster resource “<cluster disk name>” /listowners</i>

Listing possible owners for resource ‘Cluster Disk 5′:
Possible Owner Nodes

Uninstalling an MSI package

<p>There are a few ways to uninstall an MSI package. </p>

<li>If you have access to the original MSI used for the installation, you can simply <strong>right click</strong> it in <strong>Windows Explorer</strong> and select <strong>Uninstall</strong>.</li>
<li>As stated above you can do the same by command line:
<strong><em>msiexec /x filename.msi /q</em></strong></li>

<p><hr /></p>

<li>Just got to mention the normal approach though it is obvious </li>
<li>Go start -> run -> appwiz.cpl -> ENTER in order to open the add/remove programs applet (or click add/ remove programs in the control panel)</li>
<li>Click “Remove” for the product you want to uninstall.</li>

<p><hr /></p>

<li>You can locate the required code to pass to <strong>msiexec.exe /x</strong> by opending regedit.exe at <strong>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall</strong> and search for the application name (or just browse through each sub folder till u find it).</li>
<li>When you have found it you can pass it to msiexec as explained above: <strong>msiexec.exe /x {0077A7C7-3333-2222-1111-111111111000}</strong></li>

<p><hr /></p>

<li>MSI strips out all cabs and caches each MSI installed in a super hidden system folder at <strong>%SystemRoot%\Installer</strong> (you need to show hidden files to see it).</li>
<li>All the MSI files here will have a random name assigned, but you can get information about each MSI by showing the Windows Explorer status bar (View -> Status Bar) and then selecting an MSI. The summary stream from the MSI will be visible at the bottom of the Windows Explorer window.</li>
<li>Once you find the right MSI, just right click it and go Uninstall.</li>

<p><hr /></p>

<li>Also remember that an uninstall can be initiated using the WMIC command:

wmic product get name –> This will list the names of all installed apps

wmic product where name=’myappsname’ call uninstall –> this will uninstall the app.
<li><p>Finally you can uninstall an MSI via the <a href=”” rel=”nofollow”>Windows Installer Automation api</a> </p>

<p>Const msiUILevelNone = 2</p>

<p>Set objInstaller = CreateObject(“WindowsInstaller.Installer”)
objInstaller.UILevel = msiUILevelNone
objInstaller.InstallProduct( “product.msi”, “REMOVE=ALL”)
Set objInstaller = Nothing</p></li>

Warning: Attribute userAccountControl of when running DCDIAG

I just ran DCdiag on one of my DC’s and found the following warning:


C:\Windows\system32>dcdiag /q
Warning: Attribute userAccountControl of <DomainController1> is:
Typical setting for a DC is
This may be affecting replication?

So, where did this come from?

After some looking, I found the following:

There exist two issues/errors that can occur from the same cause, namely an incorrect set “userAccountControl” attribute value on a computer account.

For more information about the “userAccountControl” attribute see:


These are the default “userAccountControl” attribute values for the certain objects:

Typical user : 0×200 (512)
Domain controller : 0×82000 (532480)
Workstation/server: 0×1000 (4096)


When running DCDIAG on a DC with a correct “userAccountControl” attribute value, something like the following will be reported:

Starting test: MachineAccount
Checking machine account for DC ROOTDC001 on DC ROOTDC001.
* SPN found :LDAP/rootdc001.ADCORP.LAN
* SPN found :LDAP/ROOTDC001
* SPN found :LDAP/rootdc001.ADCORP.LAN/ADCORP
* SPN found :LDAP/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11._msdcs.ADCORP.LAN
* SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11/ADCORP.LAN
* SPN found :HOST/rootdc001.ADCORP.LAN
* SPN found :HOST/ROOTDC001
* SPN found :HOST/rootdc001.ADCORP.LAN/ADCORP
* SPN found :GC/rootdc001.ADCORP.LAN/ADCORP.LAN
……………………. ROOTDC001 passed test MachineAccount


When viewed with LDP, the “userAccountControl” attribute value for a normal DC computer account should be:

1> userAccountControl: 0×82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION );


When running DCDIAG on a DC with a incorrect “userAccountControl” attribute value, something like the following will be reported:

Starting test: MachineAccount
Checking machine account for DC ROOTDC001 on DC ROOTDC001.
Warning: Attribute userAccountControl of ROOTDC001 is: 0×82020 = ( UF_PASSWD_NOTREQD | UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
Typical setting for a DC is 0×82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
This may be affecting replication?
* SPN found :LDAP/rootdc001.ADCORP.LAN
* SPN found :LDAP/ROOTDC001
* SPN found :LDAP/rootdc001.ADCORP.LAN/ADCORP
* SPN found :LDAP/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11._msdcs.ADCORP.LAN
* SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11/ADCORP.LAN
* SPN found :HOST/rootdc001.ADCORP.LAN
* SPN found :HOST/ROOTDC001
* SPN found :HOST/rootdc001.ADCORP.LAN/ADCORP
* SPN found :GC/rootdc001.ADCORP.LAN/ADCORP.LAN
……………………. ROOTDC001 passed test MachineAccount


When viewed with LDP, the “userAccountControl” attribute value for the DC computer account :




When joining a server to a domain you can create the computer account during the join/promotion action OR you can pre-create the computer account using Active Directory Users and Computers and then join/promote. The latter can also occur when a server has been migrated from another domain. As part of the migration of the server the computer account is pre-created by the migration tool (e.g. ADMT) and after that server is migrated from one domain to the other!


When viewed with LDP, the “userAccountControl” attribute value for a normal server computer account should be:

1> userAccountControl: 0×1000 = ( UF_WORKSTATION_TRUST_ACCOUNT );


When viewed with LDP, the “userAccountControl” attribute value for the server computer account is:

1> userAccountControl: 0×1020 = ( UF_PASSWD_NOTREQD | UF_WORKSTATION_TRUST_ACCOUNT );


In the latter case, when promoting the server to a DC, for which a pre-created computer account was created, the following error might appear:

The operation failed because: The Active Directory Installation Wizard was unable to convert the computer account COMPUTER_NAME$ to a domain controller account. “Access is denied.”


For both scenarios, the cause is an incorrect “userAccountControl” attribute value and the solution is to reset it to a correct value.


To restore the default “userAccountControl” attribute value for the computer account you can either use LDP or ADSIEDIT.MSC. Here I will explain how to change it with ADSIEDIT.MSC.

When using ADSIEDIT.MSC:

From the command-line start ADSIEDIT.MSC
Connect to the domain NC
Navigate to the OU or container that contains the computer account of the server for which the “userAccountControl” attribute value must be changed
Right click on the computer account of the server for which the “userAccountControl” attribute value must be changed and retrieve the properties
Scroll down to the “userAccountControl” attribute
You should see some value: <some DECIMAL value>
If the server already is a DC change the value to: 532480
After this, if you use LDP you should see:
1> userAccountControl: 0×82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION );
If the server is not a DC and was being promoted to a DC, change the value to: 4096
After this, if you use LDP you should see:
1> userAccountControl: 0×1000 = ( UF_WORKSTATION_TRUST_ACCOUNT );




* This posting is provided “AS IS” with no warranties and confers no rights!
* Always test before implementing!

Exchange 2007: Single Mailbox / Multiple Users

We were faced with a nice little challenge recently here.
The normal rule about mailboxes in Exchange is simple and fairly obvious: one user, one mailbox, and vice versa.
Or that’s what I always learned…

Now, we have an account which normally logs in 2 or more times (our reception desk).
Since they log in with one account, they share a mailbox, simple as that.

Now, for our new VoiP system, these accounts need to be split up. Every phone needs a different user (at least in the setup we use).

There is a simple solution to this:

- Create the extra account(s).
- Do not mail enable this account.
- Grant this account full access & send-as permissions on the mailbox you need.
- in the Email field in AD Users & Computers, type the email address of the mailbox you want to open.
- Open outlook, auto discovery will automatically open the correct mailbox for you.

More details at


VMware & SAP

I’m currently investigating how to virtualise SAP.

We’re in the process of upgrading our SAP environment, and want it to run fully virtual.

Handy links:

SDK SPN Not Registered

When we reboot our SCOM server, we get an error message ‘SDK SPN Not Registered’

After a quick search on the internet, I found the solution to this problem on the site of Jonathan Almquest:

And another problem gone.