Posts

Take the guess work out of XPath with the Lithnet FIM Service PowerShell Module

Summary The FIM Service allows you to query for resources using a subset of the XPath 2.0 dialect. It provides a quite powerful mechanism for searching for resources, but has more than a few curiosities when it comes to constructing queries for different attribute types. The Lithnet FIM Service PowerShell module includes three cmdlets to help take the guess work out of constructing your XPath queries. New-XPathQuery The New-XPathQuery cmdlet creates a predicate that forms part of an XPath expression. The query is the Attribute = ‘value’ component of the expression New-XPathQueryGroup An XPath query group contains multiple XPath query objects, or other query groups, that are combined together with an ‘and’ or ‘or’ operator. New-XPathExpression The XPath expression wraps the query or query group with the appropriate syntax defining the object type (eg /Person[query] ) Working with different attribute types The cmdlets generate the correct syntax for each attribute type,...

Cut down on your PowerShell code with the Lithnet FIM Service PowerShell module

The FIMAutomation PowerShell module requires you to write a lot of code to perform even the most basic tasks. Let’s have a look at the following example in which Paul Williams provides some very well-written code for updating the EmployeeEndDate attribute of a user using the FIMAutomation snap-in. Now lets look at doing the same thing with the Lithnet FIM Service PowerShell module The same task requires much less code, and much easier to understand. Perhaps most importantly, we don’t need to understand the inner workings of the FIM Service itself (import changes, put operations, etc) to do something as simple as updating an attribute value. Just get, set, and save.

Version control your FIM Service configuration

Keeping track of your FIM Service configuration can seem like a daunting task. Even more so when you have multiple DEV, QA, and production instances that need to be kept consistent. We can make version controlling the FIM service a lot easier with some simple modifications to the schema, some clever scripts and a bit of process control. This post will reference the configuration management capabilities of the Lithnet FIM Service PowerShell module , but the same concepts can apply even when using your own tools. Firstly, break up your FIM service design into components. A component is a collection of resources such as sets, MPRs and workflows that come together to perform a particular function. For example, the self-service password reset functionality can be grouped together as an SSPR component. You might have a group of workflows, sets and email templates that handle expiry notifications. I generally use the following components as a starting point; User Interface (RCDCs, Nav b...

Lithnet.IdleLogoff – Log off users after periods of inactivity (with group policy support)

Image
At the University I work for, we recently had an opportunity to redesign our student lab workstation environment from scratch. One of the seemingly simple requirements we had was to ensure that after a certain period of inactivity, users were logged off the machines. Sounds simple right? Microsoft have a KB article that suggests a method to do this, but it’s not the best solution. It uses a screen saver as the timing mechanism, and starts a count-down timer in the background. If the user returns to the computer, they need to click a ‘cancel’ button that appears to stop them from being booted out. Not a very good user experience. We couldn't find anything that did what we wanted. Something that would sit in the background, unobtrusively, and just log a user out after a predetermined amount of time. Oh, and it would be nice to control that amount of time if needed rather easily. Oh, and it would also be nice to disable the auto-logout completely if needed. And if its not asking to...

Lithnet.MoveUser - replacement for Microsoft's moveuser.exe and Win32_UserProfile.ChangeOwner

Lithnet.MoveUser is a command line tool that can be used to change the owner of a profile from one user to another. It is designed to be a replacement for Microsoft's moveuser.exe tool (used for Windows XP), originally included in the Windows Resource Kit, and the Win32_UserProfile.ChangeOwner WMI method, used for Windows Vista and above. The Lithnet.MoveUser tool provides the same functionality as the other tools, but overcomes some of the shortcomings of the Microsoft provided toolsets . It does not require any scripting knowledge, provides a consistent experience across Windows XP, Vista, and Windows 7, and provides detailed logging of progress and any errors encountered. The tool will perform the following tasks Change the owner of the profile to the destination user, and update associated permissions Add the destination user to the same local groups that the source user was a member of If the source account is a local account, then it can either be deleted, disabled, or...

Building an enterprise-ready replacement for MoveUser.exe and Win32_UserProfile.ChangeOwner

Moveuser.exe Back in the early days of Windows XP, Microsoft released a tool for changing the owner of a user profile from one user to another. Moveuser.exe came in the Windows Resource Kit, and for the most part did an OK job. The most common use was for taking profiles that belonged to local user accounts, and attaching them to domain user accounts. It could also be used for migrating profiles from one domain to another, although the Active Directory Migration Tool (ADMT) was more commonly used for this task. The command line was simple enough; moveuser.exe oldusername newusername It took usernames in format of COMPUTER\username or DOMAIN\username . Once of the other nice things about moveuser.exe is that it also copied a user’s group membership on the local machine. Moveuser wasn't without its problems; Error messages returned by the tool were generally unhelpful. A single Win32 error code can't tell you a lot about why a profile migration might have failed. Moveuser.ex...

Configure Asterisk to receive incoming SIP calls

If you want people from the outside world to be able to contact you via SIP, there are a few things you need to configure. First, in FreePBX setup, click General Settings on the left hand menu, scroll down and select Yes to Allow Anonymous Inbound SIP Calls . The Asterisk configuration file sip.conf defines the parameters for accepting incoming SIP calls. We need to make some changes to this file to correctly process incoming calls. From the Trixbox Admin web page, click Asterisk , Config Edit , then sip.conf on the left hand side. Modify the contents of this file so it reflects what is shown below. [general] bindport=5060 ; UDP Port to bind to bindaddr=0.0.0.0 ; (0.0.0.0 binds to all) disallow=all allow=ulaw allow=alaw allow=gsm allow=ilbc context=from-sip-external callerid=Unknown tos=0x68 ;------------- Ryan's Mods -------------- externip= 203.214.45.124 ;required behind NAT localnet= 192.168.0.0/255.255.255.0  ;required behind NAT fromdomain= lithiumblue.com can...

Understanding DNS SRV records and SIP

Image
What are SRV records? DNS SRV records or service records are a type of DNS entry that specify information on a service available in a domain. They are typically used by clients who want to know the location of a service within a domain. For example, in an Active Directory environment, domain joined windows PCs rely on SRV records to locate domain controllers to authenticate to within their domain. A SRV record record contains the following information: Service Name: the well know name of the service Protocol: specifies if this is a TCP or UDP service Domain Name: the domain name that this record belongs to TTL: Time to Live value Class: DNS class field. This always has the value of "IN" Priority: when multiple hosts are configured for the same service, the priority determines which host is tried first Weight: A relative weight for records with the same priority Port: the TCP or UDP port that the service uses Target: the name of the host providing the service He...

Understanding the relationship between SIP and RTP

Image
Getting your head around SIP and RTP traffic flows is a little daunting at first, but its actually not all that complicated when you understand the purpose of the protocols. As its name implies, the Session Initiation Protocol is used to initiate a session between two endpoints. SIP does not carry any voice or video data itself - it merely allows two endpoints to set up connection to transfer that traffic between each other via the Real-time Transport Protocol (RTP). The SIP protocol can be, and usually is, routed through one or more SIP proxy servers before reaching its destination. It is very similar to how email is transmitted, in that multiple email servers are usually involved in the delivery process, each forwarding the message in its original form. Each email server adds a Received header to the message, to track the route the message has taken. SIP uses a Via header to track the SIP proxies that the message has passed through to get to it...