Wednesday, June 27, 2018

Find DN for AD Integrated Forest DNS record

With ADUC it is easy to find the distinguished name of an AD object. DNS records are a little more hidden. Here would be an example:


dc=ServerName,DC=MyDomain.org,CN=MicrosoftDNS,DC=ForestDnsZones,DC=STLUKES-INT,DC=ORG

Note the weirdness, the first two sections:

dc=ServerName,dc=FullDomainName combines to make an FQDN and yet section two would normally be broken up. Say you have a parent domain and a child domain. Normally a DN would look something like this

cn=ServerName,dc=ChildDomain,dc=ChildDomain,dc=Org

but for this we have

dc=ServerName,dc=ChildDomain.ParentDomain.Org

Weird!

Also if you want to look at application metadata, don't forget to include the name of a domain controller that belongs to the same domain as the machine you are running this command from:

repadmin /showobjmeta  sl1dc1 dc=xxsql01,dc=sl2.stfreds-int.org,cn=MicrosoftDNS,DC=ForestDnsZones,DC=stfreds-int,dc=org


Cheers!

Friday, June 1, 2018

Windows 2008 RTM Network Performance Tuning

Windows 2008 RTM Network Performance Tuning:
These NIC options are collectively known as the "TCP Chimney". Originally these options were designed to alleviate a servers compute CPU(s) from some of the stress of networking by offloading some functionality to the CPU on the NIC itself. Circa. 10 years ago, this caused issues because the NIC vendors made a bad job of leveraging the Microsoft APIs. In more recent times, this improved but the Microsoft APIs themselves were poorly implemented on Windows 2008 RTM (Vista kernel). I am not sure I would recommend baking the following recommendations in to a build image, but certainly for troubleshooting poor performance or dropped packets, these parameters can be useful. Note:


  • You may need to experiment.
  • These specifically worded parameters apply to the VMWare VMXNet3 NIC but should be found on all NICS.
  • Offloading networking traffic to the compute CPU assumes that the compute CPU is powerful enough

IPv4 Checksum Offload
When data comes in through a network, the data is checked against a checksum (or validation code) in the headers in the packets it was delivered in. If the data and checksum don't match, the packet is determined to be bad and has to be retransmitted. To speed things up, some network cards can "offload" the checksumming, i.e., perform the checksumming on the network card itself, rather than leave the job to the CPU. This frees up the CPU to do that much more work on its own, and on a server with extremely high network throughput, that much CPU savings can add up.
Recommendation: Disable

IPv4 TSO Offload
Using TSO and LRO on physical and virtual machine NICs improves the performance of ESX/ESXi hosts by reducing the CPU overhead for TCP/IP network operations. The host uses more CPU cycles to run applications. If TSO is enabled on the transmission path, the NIC divides larger data chunks into TCP segments. If TSO is disabled, the CPU performs segmentation for TCP/IP.
Note: TSO is referred to as LSO (Large Segment Offload or Large Send Offload) in the latest VMXNET3 driver attributes.
Recommendation: Disable

Large Send Offload V2 (IPv4)
Is a feature on modern Ethernet adapters that allows the TCP\IP network stack to build a large TCP message of up to 64KB in length before sending to the Ethernet adapter. Then the hardware on the Ethernet adapter — what I’ll call the LSO engine — segments it into smaller data packets (known as “frames” in Ethernet terminology) that can be sent over the wire. This is up to 1500 bytes for standard Ethernet frames and up to 9000 bytes for jumbo Ethernet frames.  In return, this frees up the server CPU from having to handle segmenting large TCP messages into smaller packets that will fit inside the supported frame size
Recommendation: Disable

Offload IP Options
Miscellaneous IP options
Recommendation: Disable

Offload TCP Options
Miscellaneous TCP Options
Recommendation: Disable

Receive Side Scalling
RSS enables driver stacks to process send and receive-side data for a given connection on the same CPU. Typically, an overlying driver (for example, TCP) sends part of a data block and waits for an acknowledgment before sending the balance of the data. The acknowledgment then triggers subsequent send requests. The RSS indirection table identifies a particular CPU for the receive data processing. By default, the send processing runs on the same CPU if it is triggered by the receive acknowledgment. A driver can also specify the CPU (for example, if a timer is used).
Recommended: Enable

TCP Checksum Offload (IPv4)
The TCP header contains a 16-bit checksum field which is used to verify the integrity of the header and data. For performance reasons the checksum calculation on the transmit side and verification on the receive side may be offloaded from the operating system to the network adapter. 
Recommendation: Disable

Rx Ring #1
 Modern and performance/server grade network interface have the capability of using transmit and receive buffer description ring into the main memory. They use direct memory access (DMA) to transfer packets from the main memory to carry packets independently from the CPU. The usual default buffering values for regular desktop NICs are 256 or 512 bytes. High performances NICs can achieve up to 4096 and/or 8192 bytes.
Recommendation: 4096

Small Rx Buffers
Where Rx Ring #1 defines the size of each buffers, 'Small Rx Buffers' defines how many buffers there are.
Recommendation: 8192

Cheers!

Thursday, April 12, 2018

Need to check secure channel on server

If Need to check secure channel on a server (or indeed a workstation) you can use this command:

nltest  /sc_query:MyCoolDomainName

Cheers!

Domain Controller has incorrect account flags

DCDIAG may reveal the following warning:

Starting test: MachineAccount
Warning:  Attribute userAccountControl of SL1CDC4 is:
 0x82020 = ( PASSWD_NOTREQD | SERVER_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION )

Typical setting for a DC is

0x82000 = ( SERVER_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION )

This maybe affecting replication

It is a bug when we pre-create a computer account in ADUC and then promote it as DC, the UserAccountControl is set to 532512 instead of the default 532480. You need to manually set the vaulue to 532480 in ADSIEDIT.MSC or with the following PowerShell

get-adobject -filter "objectcategory -eq 'computer'" -searchbase "ou=domain controllers,dc=contoso,dc=loc" -searchscope subtree -properties distinguishedname,useraccountcontrol|select distinguishedname,name,useraccountcontrol|where {$_.useraccountcontrol -ne 532480}|%{set-adobject -identity $_.distinguishedname -replace @{useraccountcontrol=532480} -whatif}

Also, this can also involve the Primary Group IDs. Here is the full summary:

RW DC
if you have RODCs then the values should be:

Useraccountcontrol = 0x82000

PrimaryGroupID = 516
  
RO DC
Useraccountcontrol = 0x5001000
PrimaryGroupID = 521

Tuesday, April 10, 2018

DNS Resolution


DNS Resolution
DNS processes and interactions involve the communications between DNS clients and DNS servers during the resolution of DNS queries and dynamic update, and between DNS servers during name resolution and zone administration. Secondary processes and interactions depend on the support for technologies such as Unicode and WINS.

How DNS queries work
When a DNS client needs to look up a name used in a program, it queries DNS servers to resolve the name. Each query message the client sends contains three pieces of information, specifying a question for the server to answer:

A specified DNS domain name, stated as a fully qualified domain name (FQDN).

A specified query type, which can either specify a resource record (RR) by type or a specialized type of query operation.

A specified class for the DNS domain name. For DNS servers running the Windows operating system, this should always be specified as the Internet (IN) class.

For example, the name specified could be the FQDN for a computer, such as “host-a.example.microsoft.com.”, and the query type specified to look for an address (A) RR by that name. Think of a DNS query as a client asking a server a two-part question, such as “Do you have any A resource records for a computer named ‘hostname.example.microsoft.com.’?” When the client receives an answer from the server, it reads and interprets the answered A RR, learning the IP address for the computer it asked for by name.

DNS queries resolve in a number of different ways. A client can sometimes answer a query locally using cached information obtained from a previous query. The DNS server can use its own cache of resource record information to answer a query. A DNS server can also query or contact other DNS servers on behalf of the requesting client to fully resolve the name, and then send an answer back to the client. This process is known as recursion.

In addition, the client itself can attempt to contact additional DNS servers to resolve a name. When a client does so, it uses separate and additional queries based on referral answers from servers. This process is known as iteration.

In general, the DNS query process occurs in two parts:

A name query begins at a client computer and is passed to a resolver, the DNS Client service, for resolution.

When the query cannot be resolved locally, DNS servers can be queried as needed to resolve the name.


Both of these processes are explained in more detail in the following sections.

DNS Resolution Overview

As shown in the initial steps of the query process, a DNS domain name is used in a program on the local computer. The request is then passed to the DNS Client service for resolution using locally cached information. If the queried name can be resolved, the query is answered and the process is completed.

The local resolver cache can include name information obtained from two possible sources:

If a Hosts file is configured locally, any host name-to-address mappings from that file are loaded into the cache when the DNS Client service is started.

Resource records obtained in answered responses from previous DNS queries are added to the cache and kept for a period of time.

If the query does not match an entry in the cache, the resolution process continues with the client querying a DNS server to resolve the name.

Overview of DNS Query Process



As indicated in the preceding figure, the client queries a preferred DNS server. The server used during the initial client/server query is selected from a global list.

When the DNS server receives a query, it first checks to see if it can answer the query authoritatively based on resource record information contained in a locally configured zone on the server. If the queried name matches a corresponding RR in local zone information, the server answers authoritatively, using this information to resolve the queried name.

If no zone information exists for the queried name, the server then checks to see if it can resolve the name using locally cached information from previous queries. If a match is found here, the server answers with this information. Again, if the preferred server can answer with a positive matched response from its cache to the requesting client, the query is completed.

If the queried name does not find a matched answer at its preferred server — either from its cache or zone information — the query process can continue, using recursion to fully resolve the name. This involves assistance from other DNS servers to help resolve the name. By default, the DNS Client service asks the server to use a process of recursion to fully resolve names on behalf of the client before returning an answer.

In order for the DNS server to do recursion properly, it first needs some helpful contact information about other DNS servers in the DNS domain namespace. This information is provided in the form of root hints, a list of preliminary RRs that can be used by the DNS service to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree. Root servers are authoritative for the domain root and top-level domains in the DNS domain namespace tree.

By using root hints to find root servers, a DNS server is able to complete the use of recursion. In theory, this process enables any DNS server to locate the servers that are authoritative for any other DNS domain name used at any level in the namespace tree.

For example, consider the use of the recursion process to locate the name “host-b.example.microsoft.com.” when the client queries a single DNS server. The process occurs when a DNS server and client are first started and have no locally cached information available to help resolve a name query. It assumes that the name queried by the client is for a domain name of which the server has no local knowledge, based on its configured zones.

First, the preferred server parses the full name and determines that it needs the location of the server that is authoritative for the top-level domain, “com”. It then uses an iterative query to the “com” DNS server to obtain a referral to the “microsoft.com” server. Next, a referral answer comes from the “microsoft.com” server to the DNS server for “example.microsoft.com”.

Finally, the “example.microsoft.com.” server is contacted. Because this server contains the queried name as part of its configured zones, it responds authoritatively back to the original server that initiated recursion. When the original server receives the response indicating that an authoritative answer was obtained to the requested query, it forwards this answer back to the requesting client and the recursive query process is completed.

Although the recursive query process can be resource-intensive when performed as described above, it has some performance advantages for the DNS server. For example, during the recursion process, the DNS server performing the recursive lookup obtains information about the DNS domain namespace. This information is cached by the server and can be used again to help speed the answering of subsequent queries that use or match it. Over time, this cached information can grow to occupy a significant portion of server memory resources, although it is cleared whenever the DNS service is cycled on and off.


The following three figures illustrate the process by which the DNS client queries the servers on each adapter.


Querying the DNS Server, Part 1



Querying the DNS Server, Part 2



Querying the DNS Server Part 3



The DNS Client service queries the DNS servers in the following order:

The DNS Client service sends the name query to the first DNS server on the preferred adapter’s list of DNS servers and waits one second for a response.

If the DNS Client service does not receive a response from the first DNS server within one second, it sends the name query to the first DNS servers on all adapters that are still under consideration and waits two seconds for a response.

If the DNS Client service does not receive a response from any DNS server within two seconds, the DNS Client service sends the query to all DNS servers on all adapters that are still under consideration and waits another two seconds for a response.

If the DNS Client service still does not receive a response from any DNS server, it sends the name query to all DNS servers on all adapters that are still under consideration and waits four seconds for a response.

If it the DNS Client service does not receive a response from any DNS server, the DNS client sends the query to all DNS servers on all adapters that are still under consideration and waits eight seconds for a response.

If the DNS Client service receives a positive response, it stops querying for the name, adds the response to the cache and returns the response to the client.

If the DNS Client service has not received a response from any server within eight seconds, the DNS Client service responds with a timeout. Also, if it has not received a response from any DNS server on a specified adapter, then for the next 30 seconds, the DNS Client service responds to all queries destined for servers on that adapter with a timeout and does not query those servers.

If at any point the DNS Client service receives a negative response from a server, it removes every server on that adapter from consideration during this search. For example, if in step 2, the first server on Alternate Adapter A gave a negative response, the DNS Client service would not send the query to any other server on the list for Alternate Adapter A.

The DNS Client service keeps track of which servers answer name queries more quickly, and it moves servers up or down on the list based on how quickly they reply to name queries.

The following figure shows how the DNS client queries each server on each adapter.


Alternate query responses
The preceding description of DNS queries assumes that the process ends with a positive response returned to the client. However, queries can return other answers as well. These are the most common query answers:

  • An authoritative answer
  • A positive answer
  • A referral answer
  • A negative answer

An authoritative answer is a positive answer returned to the client and delivered with the authority bit set in the DNS message to indicate the answer was obtained from a server with direct authority for the queried name.

A positive response can consist of the queried RR or a list of RRs (also known as an RRset) that fits the queried DNS domain name and record type specified in the query message.

A referral answer contains additional RRs not specified by name or type in the query. This type of answer is returned to the client if the recursion process is not supported. The records are meant to act as helpful reference answers that the client can use to continue the query using iteration. A referral answer contains additional data such as RRs that are other than the type queried. For example, if the queried host name was “www” and no A RRs for this name were found in this zone but a CNAME RR for “www” was found instead, the DNS server can include that information when responding to the client. If the client is able to use iteration, it can make additional queries using the referral information in an attempt to fully resolve the name for itself.

A negative response from the server can indicate that one of two possible results was encountered while the server attempted to process and recursively resolve the query fully and authoritatively:

An authoritative server reported that the queried name does not exist in the DNS namespace.

An authoritative server reported that the queried name exists, but no records of the specified type exist for that name.

The resolver passes the results of the query, in the form of either a positive or negative response, back to the requesting program and caches the response.

If the resultant answer to a query is too long to be sent and resolved in a single UDP message packet, the DNS server can initiate a failover response over TCP port 53 to answer the client fully in a TCP connected session.

Disabling the use of recursion on a DNS server is generally done when DNS clients are being limited to resolving names to a specific DNS server, such as one located on your intranet. Recursion might also be disabled when the DNS server is incapable of resolving external DNS names, and clients are expected to fail over to another DNS server for resolution of these names. If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

By default, DNS servers use several default timings when performing a recursive query and contacting other DNS servers. These defaults include:

A recursion retry interval of 3 seconds. This is the length of time the DNS service waits before retrying a query made during a recursive lookup.

A recursion timeout interval of 8 seconds. This is the length of time the DNS service waits before failing a recursive lookup that has been retried.

Under most circumstances, these parameters do not need adjustment. However, if you are using recursive lookups over a slow-speed wide area network (WAN) link, you might be able to improve server performance and query completion by making slight adjustments to the settings.










Wednesday, January 17, 2018

Windows Firewall, determining required ports

Just a quick note on using Microsoft SysInternal utilities with the Windows firewall log.

For this worked example I am going to communicate with the target server (the server with the firewall) using PSEXEC for remote execution. You could just as easily work on the sever console or use PowerShell.

As usual, I like to explain by real-life example.

A colleague is setting up a Windows Print Server and Microsoft have provided the required protocols and ports to be opened, surprise, surprise the information is incomplete.

Step One
Examine the Windows Firewall Log. By default is resides at:

\\MyServerName\c$\Windows\System32\LogFiles\Firewall 

We can see that when the engineer tries to remotely install a driver, packets are dropped. In the log it looks like this (I have removed the date and time for brevity)

You can look at the heading in the firewall log, but I have highlighted the destination port.

DROP TCP 10.150.85.240 10.20.68.183 12387 9001 48 S 4157967098 0 8192 - - RECEIVE
DROP TCP 10.150.85.240 10.20.68.183 12388 9001 48 S 3357802324 0 8192 - - RECEIVE

In this imaginary scenario, it looks like we are dropping TCP 9001 (if you already know what that is, pretend you don't for the sake of this tutorial). So the next step would be to track down what that port is being used for and whether we should be opening it. We need to get onto that server, either:


  • PowerShell
  • Console
  • RDP
  • PSEXEC

First we will run the built-in Windows tool 'NetStat' using the syntax:

netstat  -an -o

Which will display all the ports on which the server is listening. The '-an' means supress the resolution of the IP address to which to the server may have a connection. This makes the command run much faster. The '-o' means display the running process which is what we want. The output will look something like this:


Active Connections

Proto Local Address         Foreign Address  State           PID
TCP   0.0.0.0:135           0.0.0.0:0        LISTENING       992
TCP   0.0.0.0:445           0.0.0.0:0        LISTENING       4
TCP   0.0.0.0:5357          0.0.0.0:0        LISTENING       4
TCP   0.0.0.0:5985          0.0.0.0:0        LISTENING       4
TCP   0.0.0.0:8081          0.0.0.0:0        LISTENING       3812
TCP   0.0.0.0:8092          0.0.0.0:0        LISTENING       4
TCP   0.0.0.0:8495          0.0.0.0:0        LISTENING       3812
TCP   0.0.0.0:47001         0.0.0.0:0        LISTENING       4
TCP   0.0.0.0:49664         0.0.0.0:0        LISTENING       680
TCP   0.0.0.0:49665         0.0.0.0:0        LISTENING       884
TCP   0.0.0.0:49666         0.0.0.0:0        LISTENING       1320
TCP   0.0.0.0:49669         0.0.0.0:0        LISTENING       2212
TCP   0.0.0.0:49670         0.0.0.0:0        LISTENING       760
TCP   0.0.0.0:49699         0.0.0.0:0        LISTENING       752
TCP   0.0.0.0:49710         0.0.0.0:0        LISTENING       3812
TCP   0.0.0.0:49713         0.0.0.0:0        LISTENING       760
TCP   10.150.210.201:9001   0.0.0.0:0        LISTENING       42
TCP   10.150.210.201:50495  10.20.104.6:443  ESTABLISHED     10744
TCP   10.150.210.201:50496  10.20.104.6:443  ESTABLISHED     10744
TCP   10.150.210.201:50497  10.20.104.6:443  ESTABLISHED     10744

We can see (highlighted) that port 9001 is being listened to by a process with PID (Process ID) 42. We now need to know what that process is. We can use the SysInternals tool 'tasklist', just run it and it should produce an output something like this (I have trimmed the output for clarity):

Image Name             PID SessionName    Session# Mem Usage
====================  ==== =============  =======  ===========
System Idle Process      0 Services        0             4 K
System                   4 Services        0         2,764 K
svchost.exe            836 Services        0        23,516 K
svchost.exe            884 Services        0        16,544 K
svchost.exe           1104 Services        0        26,160 K
WUDFHost.exe          1184 Services        0         2,984 K
svchost.exe           1320 Services        0        65,344 K
dasHost.exe           1744 Services        0         6,912 K
svchost.exe           2020 Services        0         6,648 K
hpservice.exe         1256 Services        0         1,144 K
svchost.exe           1080 Services        0         4,808 K
svchost.exe           2156 Services        0         9,364 K
spoolsv.exe             42 Services        0        16,140 K
wrapper.exe           2408 Services        0         2,336 K
mDNSResponder.exe     2424 Services        0         2,832 K

If we examine this list we can see (highlighted) that PID 9001 is 'spoolsv.exe' so this all provides us with a set of clues:


  1. When we investigate the origin of the dropped traffic in the firewall log we discover that the IP belongs to the workstation we are testing our PrintServer from.
  2. Researching port 9001 reveals it to be the HP JetDirect printing port.
  3. Spoolsv.exe is the Windows Print Spooler.
So good bet this is something we need to open on the firewall of the printserver.


Monday, October 30, 2017

Copy DACL from one folder to another

If you ever need to copy the access rights from one folder to another, this will help. This is also useful in cases where you need to duplicate the permissions from a folder to a recently re-created junction link.

Get-Acl -Path  SourceFolder | Set-Acl -Path  DestinationFolder

Here is an example:

Original State

  • There is a folder on the G: drive called 'Medicine'
  • There is a junction point on 'E:\Shared\Medicine' which points to the folder.
  • The permissions on the junction point are identical and complex

Some hero then deletes the junction point. This is then recreated thus:

mklink /j "E:\Shared\Medicine" "G:\Medicine"

We can then restore the junction link's missing DACL using PowerShell thus:

Get-Acl -Path "G:\Medicine" | Set-Acl -Path  "E:\Shared\Medicine"


Cheers!

Wednesday, August 2, 2017

Dump or Search for SPN records

Here you go:

#########################
$SearchCriteria = "CX"  # ----- What you search for
#########################
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$search.filter = "(servicePrincipalName=*)"
$results = $search.Findall()
Foreach($result in $results)
{
$userEntry = $result.GetDirectoryEntry()
If($($userEntry.name) -like "*$SearchCriteria*")
{
Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" -foregroundcolor "black"
Write-host "DN      =      "  $userEntry.distinguishedName
Write-host "Object Cat. = "  $userEntry.objectCategory
Write-host "servicePrincipalNames"
$i=1
foreach($SPN in $userEntry.servicePrincipalName)
{
Write-host "SPN(" $i ")   =      " $SPN       $i+=1
}
Write-host ""
}
}

Saturday, July 22, 2017

Switch off ellipses in Scrivener


So you want Scrivener to stop converting three periods into an ellipses? You think you need to switch off them bottom of the to options in the picture below? No - you have to switch off BOTH of the options below because the two are linked within the Apple API. This in not a Scrivener issue.

Cheers!




Wednesday, July 12, 2017

Event ID 7023 "The Data Sharing Service service terminated with the following error: %%3239247876"

You may see this on Server 2016 which may shutdown all file shares.

This is caused by the UAL Service ('User Access Logging Service'), which is responsible for logging access requests to the Security Event Log coming into conflict with the DS Service ('Data Sharing Service'), which is obviously responsible for file sharing.

They are conflicting as they try so share certain system DLLs.

The solution is to reconfigure both services to reserve their own (tiny) memory space. This can be achieved using the Service Configuration Tool (sc.exe) thus:

Sc config ualsvc type=own 
Sc config dssvc type=own

Cheers!

Tuesday, July 11, 2017

Default Permissions Issues in Server 2016

* This article published in a hurry, will tidy later *

This error:

Log Name:      System
Source:        Microsoft-Windows-DistributedCOM
Date:          7/11/2017 9:04:32 AM
Event ID:      10016
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      SL2TDC4.MyDomain.ORG
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID 
{8D8F4F83-3594-4F07-8369-FC3C3CAE4919}
 and APPID 
{F72671A9-012C-4725-9D2F-2A4D32D65169}
 to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

So this is a permissions issue related to the 'Connected Devices Platform' and can cause the NIC to fail during Windows updates. Here is now to fix:



  • Open REGEDIT navigate to HKEY_CLASSES_ROOT\CLSID\{8D8F4F83-3594-4F07-8369-FC3C3CAE4919}
  • Right-Click, select permissions
  • Click Advanced
  • Change Ownership to Administrators
  • Check the "replace all child object permissions entries with inheritable permissions from this object' checkbox
  • Click OK
  • Click YES
  • Edit permissions to provide Administrators FULL CONTROL if it is not already set.
  • Now go to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{F72671A9-012C-4725-9D2F-2A4D32D65169}
  • Right-Click, select permissions
  • Click Advanced
  • Change Ownership to Administrators
  • Check the "replace owner on subcontainers and objects' checkbox
  • Click OK
  • Click YES
  • Edit permissions to provide Administrators FULL CONTROL if it is not already set.

  • Next, run COMEXP from an admin cmd prompt
  • Navigate down to Component Services\My Computer\DCOM Config\{F72671A9-012C-4725-9D2F-2A4D32D65169}
  • Right-Click select properties then the Security tab
  • Select Customize on the 'Launch and Activation Permissions'
  • Select Edit
  • Add Local Service from the local SAM
  • Check 'Local Activation'
  • OK, OK
  • Reboot
Repeat for all instances of EventID 10016 (System Event Log)

Connected Devices Platform (NIC Disconnects)
CLSID  {8D8F4F83-3594-4F07-8369-FC3C3CAE4919}

APPID  {F72671A9-012C-4725-9D2F-2A4D32D65169}

RuntimeBroker (Memory Leak)
CLSID  {D63B10C5-BB46-4990-A94F-E40B9D520160}

APPID  {9CA88EE3-ACB7-47C8-AFC4-AB702511C276}





Saturday, July 8, 2017

Icons wrong on Microsoft Office Documents (Mac OS)

Delete /Library/Caches/com.apple.iconservices.store.

You will need to enter your administrator password for this

Reboot

Cheers!

Friday, July 7, 2017

Redirect HOME folders on a Mac

I have always liked to separate my data from the system files on my Mac. That way I can use TimeMachine to restore an earlier version of my system drive without worrying about reverting my documents and vice-versa. Call it personal style, but this is how you do it:

I will take you through processing the DOCUMENTS folder, then you can rinse and repeat for MUSIC, PICTURES or whatever you want.

* DON'T BE A MORON, BACKUP YOUR DATA FIRST *

  • Create your target folder on your separated data drive. In my case a folder called 'Documents'
  • Now we need to maintain the icon the easy way before we lose it by deleting the original folder. So, open a Get-Info window for both the original and the new folders. At the tippy-top of the Get-Info window is a miniature version of the icon. We are going to copy and paste it from the original to the new. Its a little weird because don't bother right-clicking for a context menu, there isn't one. This is what you do - click the miniature version of the original and the icon will have a glow around it. CTRL-C. Go to the miniature icon in the Get-Info for the new folder, click it until it glows. CTRL-V.
  • The next step is to replace the existing 'Documents' folder with a junction link. Since it will replace the existing 'Documents' folder we need to delete it. (Repeat) we will be deleting the documents folder, so BACK IT UP!
  • Launch a terminal window and enter
chmod -R -N ~/Documents

  • That will change the permission on that folder to allow you to delete it, now we will delete it.
rm -rf ~/Documents
  • You should see your regular Documents folder vanish. It may come back after a few seconds as some Apple watchdog process corrects what it thinks is an error condition. Don't worry just run it again and move on to the next command as quickly as you can, and that is to create the junction link that replaces the regular folder and points to your new folder:
ln -s /Volumes/Data/Documents
  • Replace the word 'Data' with the name of the drive that contains your new Documents folder.
  • Job done, you should now have a redirect in place. You can prove that by manually placing a file in the new folder, then navigate to your Documents folder using the 'GO' menu on the taskbar.
Cheers!




Sunday, June 25, 2017

Saturday, May 27, 2017

Error 0x80070070

The shortest post ever...

Error: 0x80070070

Means whatever you were doing ran out of disk space.

Cheers!


Wednesday, February 15, 2017

Microsoft Azure VM Sizes

Here is a useful list of Azure VM sizes, the XML parameter is what you would use in the configuration files for your PaaS instance. Specifically the 'ServiceDefinition.csdef' file. For example:

WorkerRole name="MyCacheWorkerRole" vmsize="Medium"


 VM Size in Azure

(note the use of descriptive words instead of codes in model A0 through A4)

Modern Title
Parameter in XML
Cores
Memory
(GB)
Local Disk Size
(GB)
NICs
Bandwidth
A0
ExtraSmall
1
0.756
20
1
Low
A1
Small
11
1.75
225
1
Medium
A2
Medium
2
3.5
490
1
Medium
A3
Large
3
7
1000
2
High
A4
ExtraLarge
8
14
2040
4
High
A5
A5
2
14
490
1
Medium
A6
A6
4
28
1000
2
High
A7
A7
8
56
2040
4
High
A8
A8
8
56
1817
2
High
A9
A9
16
112
1817
4
Very High
A10
A10
8
56
1817
2
High
A11
A11
16
112
1817
4
Very High
A1 v2
Standard_A1_ v2
1
2
10
1
Medium
A2 v2
Standard_A2_v2
2
4
20
2
Medium
A4 v2
Standard_A4_v2
4
8
40
4
High
A8 v2
Standard_A8_v2
8
16
80
8
High
A2m v2
Standard_A2m_v2
2
16
20
2
Medium
A4m v2
Standard_A4m_v2
4
32
40
4
High
A8m v2
Standard_A8m_v2
8
64
80
8
High
D1
Standard_D1
1
3.5
50
1
Medium
D2
Standard_D2
2
7
100
2
High
D3
Standard_D3
4
14
200
4
High
D4
Standard_D4
8
28
400
8
High
D11
Standard_D11
2
14
100
2
High
D12
Standard_D12
4
28
200
4
High
D13
Standard_D13
8
56
400
8
High
D14
Standard_D14
16
112
800
8
Very High
D1 v2
Standard_D1_v2
1
1
3.5
1
Medium
D2 v2
Standard_D2_v2
2
2
7
2
High
D3 v2
Standard_D3_v2
4
4
14
4
High
D4 v2
Standard_D4_v2
8
8
28
8
High
D5 v2
Standard_D5_v2
16
16
56
8
Extremely High
D11 v2
Standard_D11_v2
2
14
100
2
High
D12 v2
Standard_D12_v2
4
28
200
4
High
D13 v2
Standard_D13_v2
8
56
400
8
High
D14 v2
Standard_D14_v2
16
112
800
8
Extremely High
D15 v2
Standard_D15_v2
20
140
1000
8
Extremely High
G1
Standard_G1
2
28
384
1
High
G2
Standard_G2
4
56
768
2
High
G3
Standard_G3
8
112
1536
4
Very High
G4
Standard_G4
16
224
3072
8
Extremely High
G5
Standard_G5
32
448
6144
8
Extremely High
H8
Standard_H8
8
56
1000
8
High
H16
Standard_H16
16
112
2000
8
Very High
H8m
Standard_H8m
8
112
1000
8
High
H16m
Standard_H16m
16
224
2000
8
Very High
H16r
Standard_H16r
16
112
2000
8
Very High
H16mr
Standard_H16mr
16
224
2000
8
Very High