Azure: Changing the IP Address (VNET) of a Virtual Machine

Moving Azure Virtual Machines to a New VNET

In the prior blog post, I moved my Azure virtual machines from the Azure Service Manager (ASM) to Azure Resource Manager (ARM) model. In this blog post, I walkthrough how to change the IP address of the Azure Virtual Machine  from one VNET to another VNET. What does this mean?

This scenario would come up if you needed to change the IP addresses of your Azure virtual machines to a different network. For example, suppose you needed to change the IP addresses of your Azure virtual machines from 10.0.1.0/24 (in VNET1) to a new range (10.0.2.x/24 in VNET2.

It turns out that if you need to move the virtual machine to another network, that you will need to delete and recreate the virtual machine in the new VNET.  During this process, you only delete the virtual machine configuration and then recreate it and re-attach the VM virtual disk (VHD).

Changing Availability Sets Also Require Virtual Machine Recreation

We also discovered that in order to put the virtual machine into the correct availability set that this can only be done at creation. After our ASM to ARM migration, some of our VM’s were not in the correct availability set, so I wanted to correct this issue as well.

 

The Process..

Luckily, I found a blog post that documents this process. It can be found at:

https://blogs.technet.microsoft.com/espoon/2016/03/11/moving-an-arm-vm-to-a-new-vnet/

 

In this blog post, I’ll document the lessons learned as I went through this process.

Step 1: Document the current VM

  • I documented the current configuration of my Azure virtual machines. Two key things that I needed to record were: the VM size and the storage location of the Azure VM.
  • To get the VM size, go to the Overview page and it should be listed.

pic-b1

  • To get the storage location, go to Disks on the VM properties. Then on the right, go to OS Disk and select the disk under the label.

pic-b2

  • Then copy the storage location of the actual VHD file for the virtual machine. This is key. Since during the process, we are deleting the VM construct. However, we are not touching the VM VHD file. We will be re-building the VM and re-attaching to the existing VHD file in the new VNET.

pic-b3

 

Things to Do Before the Migration:

 

Disable Network Level Authentication Temporarily Before Migration

Before you move the VM’s to a new network, you may want to disable NLA during the time of the migration. I encountered the following error (see below) after the migration when I tried to RDP into the migrated VM. The migrated VM couldn’t connect to the domain controller so I wasn’t able to RDP into it since RDP required Network Level Authentication (NLA). So, I had to migrate back the VM so that it could connect to the domain controller. Then, I was able to disable NLA. I brought this up early so you can make this change before the migration. If you don’t do this, you maybe able to fix it after the migration, if you move the domain controller to the new VNET and also set the DNS on the VNET to point to the domain controller so that the VM can connect to the domain controller. However, I would recommend disabling it before the migration.

pic-b4

To disable NLA, RDP into the VM, go to the Properties and Remote settings of the server. Select Remote Settings and un-check the “Allow connections only from computers running Remote Desktop with NLA”.

pic-b5

Create Availability Sets Before Migration

Since you need to set the availability set during the VM creation, you need to create the availability sets that you need before you move the VM’s to the new VNET location.

 

Create the destination Virtual Network (VNET) and Subnet Before Migration

Design the new IP address strategy. Create the destination virtual network (VNET) and subnet before migrating the VMs. Identify the IP addresses for the migrated VM’s.

 

Use PowerShell for the Migration

I used PowerShell commands to move the VM’s to a new VNET. I would recommend using Power Shell and using Powershell ISE since it allows you to develop a PowerShell script for the move and allows you to re-use the script to each VM’s with minor tweaks. Remember to start Powershell ISE with “Run as Administrator” (Right-click on the Powershell ISE and select “Run as Administrator”).

 

Moving the VM to a New Subnet

I would recommend testing this procedure first on a trial/test VM.

  • After recording the information, I deleted my virtual machine.
  • Then I ran the following script to recreate the virtual machine and re-attach to the VHD.

 

# Installs Azure RM modules. Login to Azure.

# Select the Azure subscription that has the VM’s that you want to work on.

Install-Module azurerm

Login-AzureRmAccount

Get-AzureRmSubscription | sort SubscriptionName | select SubscriptionName

Select-AzureRmSubscription -SubscriptionName “<Substitute the subscription that has your VMs”

 

# define variables for your environment

$networkname = “<Enter your destination VNET>”

$subnetname = “<Enter your destination subnet>”

$rg = “<Enter the resource group that holds VMs”

$PIPName = “<Enter the public IP address name, eg. Servername-pip>”

$nic1name = “<Enter the NIC name, eg. Servername-nic>”

$vmname = “<Enter the servername>”

$storageaccount = “<Enter the storage account for your VMs>”

$PIPDNSName = “<Enter the public IP DNS name, eg. Servername>”

$VMSize = “<Enter the VM size, eg. Standard_A3>”

$StorageRg = “<Enter the resource group that holds the storage account>”

$Location= “<Enter the location where you want the resources, eg. Westus>”

$vhdname = “<Enter your servername, eg. ec360dc2>”

$network=Get-AzureRmVirtualNetwork -Name $NetworkName -ResourceGroupName $networkname

$subnet=Get-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -VirtualNetwork $network

$Stor=Get-AzureRmStorageAccount -ResourceGroupName “<Enter the resource group that has your storage” -Name $storageaccount

 

$pip=New-AzureRmPublicIpAddress -Name $PIPName -ResourceGroupName $Rg -Location $Location -DomainNameLabel $PIPDNSName -AllocationMethod Dynamic

 

 

# I wanted to set a static private address in the subnet (e.g. 10.0.2.30 so I specified it on this command.

$nic1=New-AzureRmNetworkInterface -Name $Nic1Name -ResourceGroupName $Rg -Location $Location -SubnetId $subnet.Id -EnableIPForwarding -PublicIpAddressId $pip.Id -PrivateIpAddress 10.0.2.30

 

 

$as = Get-AzureRmAvailabilitySet -ResourceGroupName $rg -Name “<Enter the availability set that you want to put the VM into>”

$VM=New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize -AvailabilitySetId $as.id

$VM=Add-AzureRmVMNetworkInterface -Id $nic1.id -VM $VM -Primary

 

# This is a key variable. Need to paste in the path to the VHD storage location noted earlier

$OSDiskUri = “<Paste in the VHD storage path recorded earlier, e.g. https://###.blob.core.windows.net/vhds/ … .vhd>”

 

$VM=Set-AzureRmVMOSDisk -Name $VHDName -VhdUri $OSDiskUri -Caching ReadWrite -CreateOption attach -Windows -VM $VM

 

# Creates the VM

New-AzureRmVM -ResourceGroupName $RG -Location $location -VM $VM

 

 

After the VNET Migration

  • Confirm that each of the VM’s started.
  • Configure the Network Security Groups (NSG) to allow RDP if it doesn’t work. Need to enable inbound access to port 3389
  • If you want internet access, add the rules to the NSG for Internet and DNS.
  • Confirm that you can RDP into each of the VM’s.
  • Re-apply the Network Level Authentication (NLA) as you check each VM.

 

Advertisements
Posted in Azure, Uncategorized | Tagged | Leave a comment

Azure: Moving Virtual Machines from Classic (ASM) to Resource Management (ARM)

In this blog post, I document my experiences and lessons learned in moving my Azure virtual machines (VM) from classic Azure Service Manager (ASM) to Azure Resource Manager (ARM) deployment model. I decided to document my experience since I encountered some bumps in the migration and thought that others could benefit from how I resolved them.

Background:

If you have been using Azure for a while, you probably have created your Azure resources using the classic Service Manager (ASM) model. An easy way to check is if you have been using the classic Azure portal to manage your Azure environment (e.g. http://manage.windowsazure.com)

Microsoft released a new management model called Azure Resource Manager (ARM) which provides many new capabilities to manage, and control Azure resources. Also, there is a new management portal located at: http://portal.azure.com. For more information on Azure Resource Manager, see here

Microsoft released a set of tools to migrate your resources from the classic Service Management (ASM) model to the new Resource Manager (ARM) model. The documentation and process for the ASM to ARM migration can be found (here).

 

Migrating from ASM to ARM

I printed out the docs mentioned and began the journey of moving my virtual machines to ARM.

In Step 1 (in the docs):

  • I reviewed the planning guidance.

In Step 2 (Install the latest version of Powershell):

  • See here for more information.
  • I launched Powershell ISE on my Windows 10 machine. Be sure to launch it with Administrator credentials
  • Then, I needed to install the ARM modules from the Powershell Gallery. In the Powershell ISE, run the command:   Install-module AzureRM

pic1

(This command takes some time to download, unzip, and install the ARM Powershell module.)

  • Then, I needed to install the ASM modules from the Powershell Gallery. In the Powershell ISE, I ran the command: install-module Azure

pic2

 

(I got an error when I ran the command. The fix was in the error message. I re-ran the command with the -AllowClobber parameter.)

pic3

(This command ran successfully.)

In Step 3 (Set your subscription and sign up for migration):

  • As documented, I ran the Powershell commands:
    • Login-AzureRmAccount
    • Get-AzureRMSubscription | Sort SubscriptionName | Select SubscriptionName
    • Select-AzureRmSubscription –SubscriptionName “My Azure Subscription”   (I put my subscription name in)
    • Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
    • Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

pic4

  • Then, I needed to login to the ASM environment and ran the following Powershell commands:
    • Add-AzureAccount     [Note, if you get an error here, make sure that you loaded in the ASM Powershell modules using the Install-Module Azure]
    • Get-AzureSubscription | Sort SubscriptionName | Select SubscriptionName
    • Select-AzureSubscription –SubscriptionName “My Azure Subscription”

 

In Step 4 (Check Azure Resource Manager Virtual Machine cores):

  • As documented, I ran the Powershell commands:
    • Get-AzureRmVMUsage -Location “West US”

In Step 5 (Run commands to migrate your IaaS resources):

  • In this step, the docs separate into two sections depending upon if your resources that you want to migrate to ARM are in a virtual network or not. I needed to move my virtual machines that are in a virtual network so I skipped to the section title, “Migrate virtual machines in a virtual network.”
  • As documented, I ran the Powershell commands:
    • $vnetName = “myVnet”     [I substituted the vnet that hosts my VM’s]
    • Move-AzureVirtualNetwork –Validate -VirtualNetworkName $vnetName

pic5

(I got the message that Validation failed. Now the trick is to figure out what failed. After searching through some Powershell guides/sites, I discovered the correct syntax and run the following command to expand the Validationmessages field to see the error messages.)

    • Move-AzureVirtualNetwork –Validate -VirtualNetworkName $vnetName | select -expandproperty validationmessages

pic6

(Now, I got a bunch of error messages for all the VM’s that I was trying to migrate. I did some searching and there is a site with a list of the common errors (here). By using this site, here is a summary of the things that I did to fix the errors:

  • I shutdown my VM’s.
  • I got a bunch of errors around Availability sets. In my environment, we had multiple availability sets for each tier of the applications. The migration tool seems to only support 1 availability set across all the VM’s. I decided to remove all the Availability Sets during migration. So, I recorded the availability sets used by the virtual machines and then went through to remove them. To do this, launch the Azure Classic portal, go to the virtual machine and then the Configure tab. Then remove the Availability Set.)
    • I re-ran the Validate commands and fixed the issues until all the errors/issues were resolved.
    • Then I ran the following command: Move-AzureVirtualNetwork –Prepare -VirtualNetworkName $vnetName

pic7

(I got the error above. I did some research and one post mentioned trying to re-run the command. So, I re-ran command and it worked!)

pic8

Now, you are ready to migrate all the resources on the vnet to the ARM model. The docs state to check the configuration and if you are ready to migrate, then move to the next step by running the following command:

  • Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName

pic9

Now, you wait. After some time, the virtual machines and resources will appear in the new portal (http://portal.azure.com). The migration process will create a new resource group for each cloud service and will append “-migrated” to the name.

pic10

Since, I wanted to group all the virtual machines under one resource group. I created a new resource group and started moving all the resources into that new resource group.

After doing this, I tried to start the virtual machine and got an error. The error was focused on: KeyVaultAccessForbidden

pic13b

After reading through the error message, I discovered that the virtual machine was looking for the Azure Key Vault in the resource group that was created during the migration (with the “-migrated”). I had moved the Key Vault to the new resource group that I had created with all the rest of my migrated resources.

So, I moved the Key Vault back to the resource group that it was migrated originally into. After doing this move, the virtual machine started fine!

The lesson learned is: Don’t move the migrate Key Vault into a different resource group after the migration.

pic11

 

Posted in Azure | Tagged , , , | Leave a comment

Real Estate: My ATW Investment Update (Part 3)

This is my 3rd update post regarding my experiences investing with ATW Investments in San Antonio Texas owned by Brian Peyton.  As mentioned on my earlier 2 posts, I had purchased 3 properties from ATW back around July 2015.  Two of the properties had sold and the third was still in the rehab process.

The third property in Waco Texas finished rehab around August 3, 2016. [I’m not 100% sure of the rehab completion date since I wasn’t informed when the rehab was complete.  I have had to reach out to them every two weeks for an update.  My experience is that you have to reach out to them for updates versus them updating you.]

I had purchased the Waco property on July 31, 2015.  So, it had taken about a year to finish the rehab.  During this time, I have had to pay insurance and property taxes while making no income on the property.

As of today (October 6, 2016), the property is being marketed for sale.  So, it has been approximately 14 months since I purchased this property and still no cashflow.  Brian has offered to buy back the property from me and sell it to someone else.  However, I figure that I have waited this long if I sold it to someone else they would benefit from all of my months of waiting and expenses of carrying the property.

Also, I discovered that one of the purchasers of my other ATW property hadn’t made their mortgage payment.  So, I may end up having to foreclose on them.

In summary, I would caution any future ATW investors to consider the potential long term period of time that they will need to wait to get any return on their investment (in my 3rd case, 14 months and counting).  During this time, they will need to feed the investment by paying the monthly insurance and any property taxes.  Also, even after a property is sold, you may have the traditional real estate investment issues such as tenants/buyers not making their rent/mortgage payments and having to foreclose.

I’ll update folks when the 3rd property finally sells.  It will be a time of celebration.

Posted in Real Estate | Leave a comment

Real Estate: My ATW Experiences Update (Part 2)

I have gotten requests to write an update on my prior post regarding my experiences investing with ATW.  I have been hesitant to write an update since this experience has been trying and maybe only reflective of my experience working with ATW.  It may not be reflective of everyone else’s experience.  So given that, here is an update of my experience.

As a recap, I had purchased three properties from ATW Investments.  Two of the properties are located in Seguin, Texas and one in Waco, Texas.

The two properties in Seguin finally sold.

  • One property sold on March 8, 2016 and it took about a month to close escrow with the buyer.  I had purchased on July 27, 2015.  So, it took about 6-7 months from purchase, rehab, sale, and receipt of any funds back from my investment.  It’s interesting because the initial proforma mentioned that it would take 4-6 weeks for the rehab.  The sale price was within the range originally stated on the proforma.
  • The second property in Seguin sold on March 9, 2016 (similar to above).  I had purchased it on July 21, 2015.  So, it took about the 6-7 months to go through the  process.  This proforma stated that it would take 8-10 weeks for the rehab.

I had also purchased a property in Waco on July 31, 2015.  It is still in rehab as of the date of this post (5/22/2016).  So, it is going on 10 months of rehab.  When I ask for a status update, the reply is that it will take “two more weeks”, or we’re “waiting for an inspection.”  Brian has offered to purchase the property back.  I figured that since I have waited 10 months already.  I should  hang in there.  If I sold it back, Brian would probably sell it to the next investor and it’ll only have a short time before it finishes.

In summary, here are the downside that I have experienced.

  • I did not make any money from my investments for 6+ months.
  • I paid insurance for these properties during this whole time.  So, I have been making a monthly payment to pay for the insurance to cover the properties during the rehab.
  • I have had to also pay property taxes on the properties.   This is a pretty big expense since Texas has a high property tax.
  • I have had to reach out for updates.  ATW is not very proactive in providing status updates unless there is a status change (in my case, there has been little status change for 6 months).  I have had to reach out for updates on these properties.  During the Boot Camp, there was a mention of getting a weekly video updates.  I found these to be very sporadic.  I definitely did not get a video update every week over the last 10 months.  This overall has been a cost of my time and stress.
  • ATW has added some extra fees to the process (e.g. $50-$100 recording fee, plus some other fees).

The upsides are:

  • The two properties have sold within the parameters laid out in the proforma (e.g. sale price, and monthly rent.
  • I have been waiting for inspections on the Waco property.  So, hopefully, the inspectors are making sure that the rehab is up to code and that the rehab work meets the current standards and regulations.

 

Posted in Real Estate | 1 Comment

Office 365: Fixing Directory Synchronization (Issue #2)

In the previous blog post, I walked through how we upgraded from the Preview Azure AD Connect to the release version of Azure AD Connect in the attempts of fixing the directory synchronization issue. I thought that we had solved it until I got another e-mail from Office 365 stating that Directory Synchronization was unhealthy. I checked the Office 365 portal and noticed again that directory synchronization had not occurred in the last 70 hours.

p1

[Note: In this blog post, I refer to troubleshooting steps that I explain in the previous blog post. Please refer back to that post to get the more details].

I loaded up the Directory Synchronization tool (miisclient.exe) and noticed that synchronization had not been running since the date/time that I had installed the tool (back on 10/19).

p2

I checked the Scheduled Tasks and noticed that the DirSync task should have run today (10/22).

p3

I ran a manual full sync using the command: DirectorySyncClientCmd.exe initial

p4

I looked at the logs and noticed that the synchronization worked.

p5

I checked the portal and noticed that Office 365 registered the synchronization.

p6

It appears that the default scheduled task that was created by the Azure AD Connect installer is not working or doesn’t have the appropriate rights. So, we created a new scheduled task to run the Directory Synchronization task.

Launch the Task Scheduler and on the right, select Create task. Specify a name and give a description to alert others what the task is for.   Selected “Run whether user is logged on or not” and checked “Run with highest privileges

p7

Go to the Triggers tab. I selected New and configured the Trigger to run every “3 hours” (need to type it in) and run for a duration of “Indefinitely

p8

Go to the Actions tab. I selected New and selected Browse and browsed to the DirectorySyncClientCmd.exe

p9

Pressed ok to save the task I needed to specify the account that will perform the directory synchronization.

I then disabled the original task that was created by the Azure AD Connect installer since it wasn’t working.

p10

Then I ran the new task that I created

p11

I went to the MIISClient and confirmed that the sync job was running:

p12

I checked it later and it was still running happily.   I’ll let everyone know if I encounter another problem.

 

 

Posted in Office 365, Technology | Tagged | Leave a comment

Office 365: Fixing Directory Synchronization

I have multiple Office 365 environments and all of them having been giving me directory synchronization errors. I finally had time to research and troubleshoot these issues. So, if you are also getting the following e-mails, I’ll walk through the process that I went through to fix them.   Please note that I am just sharing the process that I went through to fix these problems. Things may change in the interim between the time of this article and your scenario.

Subject: Unhealthy Identity synchronization Notification: Wednesday, 21 October 2015 13:55:27 GMT.

Hello ###,

On Wednesday, 21 October 2015 13:55:27 GMT, Azure Active Directory did not register a synchronization attempt from the Identity synchronization tool in the last 24 hours for Microsoft [XXX].

You can troubleshoot this issue by running the Directory Synchronization troubleshooter <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgo.microsoft.com%2ffwlink%2f%3fLinkId%3d528798%26clcid%3d0x409&data=01%7c01%7cAli.Mazaheri%40microsoft.com%7cb22e1640c0c3459de66e08d2da1f518d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HLtNGlkFuOvF2peHAeYWqiqspDREPZDbws%2bMr%2bfo%2fus%3d> on the server that has Azure Active Directory identity synchronization tools installed.

Thank you,

The Azure Active Directory Team

After getting these e-mails, if you login to your Office 365 portal (http://portal.office.com), check the user replication status. On the main Office 365 Admin Center page under Users > Active Users, you can check if synchronization has been working or not. In my case, I got the warning below.

o365-admin

I ran the Directory Synchronization Troubleshooter and it wasn’t much help.

Evolution of Office 365 Synchronization Services

So, I looked at the Dir Sync server. I had “Directory Sync” tool, upgraded it to “Azure AD Sync Service” and then upgraded that to “Azure AD Connect” around April 2015. For a brief background, there has been an evolution in the Microsoft Office 365 Directory Synchronization services.   Initially, there was “Directory Synchronization Tool”. Then, the next version was called “Azure AD Sync” and now, the latest is called “Azure AD Connect”.   For a comparison of the different tools (see Here). The Azure AD Connect tool has a lot of capabilities and a great presentation to learn more about it can be found from an Microsoft Ignite presentation (here).

Directory Synchronization Tool

On the Directory Synchronization server, I checked the synchronization. To check the synchronization, launch the MIISClient.exe which can be found in:   c:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.   I would recommend making a shortcut to this program and putting it on your desktop since it is very handy.

miisclient

Once it launches, you will see the synchronization history on the Operation tab (see below). Please note that the picture below shows the results after I had fixed the problem. I forgot to grab the screenshot before I fixed the problem. When I had the problem, the operations log was missing the two “Export” jobs. The Export jobs export the changes in the Metaverse (directory database on the synchronization engine) back to the connected directories (Active Directory and Azure Active Directory). Thus, all the changes were being imported into the metaverse but weren’t being synchronized back out to the directories.

miis-client2

After much troubleshooting and a call to Microsoft support, we determined that the version of the Azure AD Connect that we had installed back around April 2015 had a problem.

[Side Note: I think that my teammate had installed the preview/beta version of the Azure AD Connect]

So, we disabled the Scheduled Task that performs the synchronization. Basically, the dir sync job is run on a scheduled task that runs every 3 hours. Open up your scheduled tasks and you will see it.

sched-task

We disabled it. Then we downloaded the latest version of the Azure AD Connect tool (here) and installed it onto a separate server.

After installing the latest version of the Azure AD Connect tool, we then initiated a full synchronization cycle.

Forcing A Directory Synchronization

To force a full synchronization cycle, you will need the DirectorySyncClientCmd.exe which can be found in: c:\program files\microsoft azure ad sync\bin

dirsynccmd

If you run the command by itself, it will initiate a directory synchronization. If you run it with the “initial” parameter, then the tool will initiate a full synchronization. After running it, the directory synchronization completed, export jobs will run, and my objects were updated in Office 365.

This was good news! Until a couple days later, I got the dreaded “Directory Synchronization error” e-mail again!

On my next blog post, I’ll walk through the steps that we took to fix the next issue that we encountered.

Posted in Office 365, Technology, Uncategorized | Tagged | Leave a comment

Real Estate: Experiences Investing with ATW Investments in San Antonio

I attended a Real Estate Boot Camp in San Antonio back on 6/29 to 7/3/2015 hosted by a company, ATW Investments.  I had signed up to attend the boot camp after listening to a Real Estate Guys Radio Show interview with the owner and founder, Brian Peyton.  Prior to signing up for the boot camp, I had done some research and didn’t find much on the Internet regarding this company.  So, based upon the recommendations of the Real Estate Radio Guys show and reviewing a webinar that Brian delivered, I signed up for the boot camp.

I want to blog about my experience working with them and hopefully by sharing my experience, others who are considering investing with them can learn from it.

At the boot camp, I learned about

  • the San Antonio and surrounding  markets,
  • Brian Peyton story
  • ATW Investment opportunities
  • Developing my own plan to achieve my goals.
  • Touring San Antonio, Waco, and Seguin markets and seeing some of the deals and getting the opportunity to purchase some.
  • Meeting his team

I was impressed at the boot camp and as a result, I purchased two properties in what ATW calls their vendor finance model and invested some money into ATW hard money lending (Upfront Capital).   Also, shortly after the boot camp, I purchased a third property in their vendor finance model.

Now, almost four months later, I wanted to blog about my experiences.

Upfront Capital:  Returns thus far 0%

  • I had invested some money with ATW’s hard money lending divison called Upfront Capital:  In this model, you provide funds to ATW and they lend it out to rehabbers who need hard money loans to complete the rehab.  As a lender, I am in first position on the liens.   The returns are said to range from 9% to 23% (averaging 17%) depending upon how often they can re-lend your funds to other rehabbers.
  • Thus far with my hard money funds, I have yielded 0%.   I have been following up with them every couple weeks and have been told that they are still trying to place my funds.

ATW Vendor Finance Investment:  Returns thus far 0%

  • In the vendor finance investment, you purchase the home and your purchase price includes the home and the rehab costs.   ATW will facilitate the rehab and then find a buyer to sell the house too and I will carry the note on the purchase.  The goal is to be the bank and collect the interest/loan payments from the buyer.
  •  Thus far, I have purchased three properties:  Two in Seguin, TX and the other in Waco, Tx.
  • It took about a month to close on the properties (end of July. 2015 to 8/17).
  • Then, I was told that ATW rehab crews were behind schedule so I have been waiting about 2 months (end of Sept) before rehab could begin.
  • My one investment in Seguin started the rehab process on 9/17.  I haven’t been given a time frame on how long the rehab will take.
  • My investment in Waco just started the rehab process and I was notified that it could take 3 months to complete the rehab because of permits.   [Side note:  I am wondering why ATW couldn’t start the permit process in the two months that I have been waiting for their rehab crews.]
  • My other investment in Seguin that I purchased after the boot camp is sitting.  I was told that their rehab team need some sort of certification before they can begin the rehab.  The rehab team was scheduled to take the exam on 10/6.  [Side note:  I am wondering why the team didn’t take this exam in the months that I had been waiting.]

I questioned Brian about this extended period and he responded that it could take up a year before an investor can expect any returns.   “The total range is 1 day to 1 year to get an investment through our system”.  Brian mentioned that he said this at the boot camp but I must have missed it.  This is a key point that other investors should consider.  You may have to wait up to a year to get any returns out of your investments.  This waiting period is not reflected in the proformas that are given out on the investments. 

On a side note, the communication from ATW is very reactive.   I have had to reach out to them all the time to get any status updates on my investment.  It appears to be that their policy is not to communicate with the investor unless something is happening.  In my case, very little has been happening over the last 4 months so they had little need to communicate.

This is the second thing to consider that if you want to know what is happening, you’ll have to be proactive in reaching out to ATW.

I will update folks as my investments go through the ATW system.

Posted in Real Estate, Uncategorized | 12 Comments